Date: Mon, 3 Jun 1996 13:57:59 -0700 (PDT) From: "JULIAN Elischer" <julian@ref.tfs.com> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: hackers@freebsd.org Subject: Re: supporting coda threads. Message-ID: <199606032058.NAA11145@ref.tfs.com> In-Reply-To: <Pine.SUN.3.91.960603100009.18045D-100000@terra> from "Ron G. Minnich" at Jun 3, 96 10:05:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > (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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606032058.NAA11145>