Date: Wed, 2 Oct 1996 14:25:55 +0100 (BST) From: Doug Rabson <dfr@render.com> To: Peter Wemm <peter@spinner.dialix.com> Cc: Michael Hancock <michaelh@cet.co.jp>, Doug Rabson <dfr@freefall.freebsd.org>, freebsd-lite2@freefall.freebsd.org Subject: Re: cvs commit: src/sys TODO Message-ID: <Pine.BSF.3.95.961002142146.10204M-100000@minnow.render.com> In-Reply-To: <199610021242.UAA00649@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Oct 1996, Peter Wemm wrote: > Doug Rabson wrote: > > On Wed, 2 Oct 1996, Michael Hancock wrote: > > > > > On Mon, 30 Sep 1996, Doug Rabson wrote: > > > > > > > dfr 96/09/30 07:20:31 > > > > > > > > Branch: sys LITE2 > > > > Added: sys TODO > > > > Log: > > > > This is a list of stuff that I think needs to be done before the lite2 > > > > filesystem code is merged into -current. Feel free to add/remove/chang > e > > > > tasks. > > > > > > I noticed we're merging in simple_lock(). > > > > I think that it would be a good idea to keep the simple_lock stuff since > > it seems to have the promise of multithreading the FS code in a future SMP > > system. It is almost certainly broken in the current tree since it is > > pretty tricky to test on a uniprocessor. There is some DEBUG code in > > kern_lock.c which looks as if it might be useful. > > A couple of points: > - Kirk McKusick is reportedly putting some serious time into doing the > VFS's so that they are fully multithreaded, and he's apparently using the > lite2 kern_lock framework. We don't want to rule out the chance of using > his code should it become available and work. (I hear he's doing some > contracting for BSDI, I wonder if the FS work is what he's doing for them? > If so, it may not be available to us). To my untutored eye, it looks as if the lite2 fs code is pretty close to being MP-safe, modulo its interface to the VM system. If Kirk is perfecting that, it would be very nice to have. Lets hope BSDI doesn't try to lock it up too tightly. [pun not intended]. > - I'm scratching my head over the SMP code's locking and am trying out > some experiments. It's looking reasonably promising that we can use the > kern_lock code to do internal kernel locking above the trap/exception/irq > layer, thus breaking the global mutex up. We can provide the raw boolean > locking primatives etc as appropriate. It's not really suitable code to > use it on the raw edge of the kernel entry points, but it looks like it > can be used above that. I was just looking at the NCPUS>1 version of the simple_locks in <machine/param.h> (that seems like a bizarre place to put them...). They are nowhere near as complicated as the SMP kernel lock. Do they have to be? > > In any case, it will certainly be interesting when the lite2 code meets > the smp code. :-) Indeed. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961002142146.10204M-100000>