From owner-freebsd-hackers Mon Jun 3 13:58:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17806 for hackers-outgoing; Mon, 3 Jun 1996 13:58:10 -0700 (PDT) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA17801 for ; Mon, 3 Jun 1996 13:58:05 -0700 (PDT) Received: (from julian@localhost) by ref.tfs.com (8.7.5/8.7.3) id NAA11145; Mon, 3 Jun 1996 13:58:00 -0700 (PDT) Message-Id: <199606032058.NAA11145@ref.tfs.com> Subject: Re: supporting coda threads. To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Mon, 3 Jun 1996 13:57:59 -0700 (PDT) From: "JULIAN Elischer" Cc: hackers@freebsd.org In-Reply-To: from "Ron G. Minnich" at Jun 3, 96 10:05:17 am X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > (from john dyson) > > One of the middle-layer VM enhancements that I plan to add for 2.2 is > > true-shared address spaces. Will this help? > > well i think it depends on the level of threading, i.e. if you use > fork()+shared address space instead of threads and the context switch > overhead is too high maybe it won't work. That's why i'm wondering about > how much threading is going on. I'm going to grab the code this week at some > point and look around. The beauty of real shared addres spaces is that it is just a reference count on the appropriate structure. that is fast, and your caches don't need to be flushed if two consecutive processes are sharing address space. Th epresent address space sharing in rfork is 'interesting' but not sufficient, because sharing processes can not see ADDITIONAL areas allocated after the fork. rfork with a REAL sharing mode as well as the present mode should yield a very quick context time and fork. These changes however are also needed for the SMP mods. > > FYI: in the ZOUNDS DSM i wrote there is a little thing called filemalloc() > and filecalloc(). Works just like malloc/calloc, except it's in mmap'ed > files so you can have shared data across fork. This is a poor man's way > to implement "threads" for those systems without rfork(). > heh! > ron > >