Date: Tue, 4 Jun 1996 17:10:34 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@Root.COM Cc: michaelv@HeadCandy.com, sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) Message-ID: <199606050010.RAA27773@phaeton.artisoft.com> In-Reply-To: <199606042336.QAA00591@Root.COM> from "David Greenman" at Jun 4, 96 04:36:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >For example, if I were to go find an OSF/1 (Digital Unix) system and > >play around with it, would that be a good representation place to > >start? Or would someone say "Oh no! Don't look at Digital Unix -- > >it's SMP support really sucks!" :-) I'm just looking for peoples' > >ideas and opinions here -- not an over-riding edict. Tell me what > >your favorite Unix SMP system is... > > You may want to take a look at Mach's SMP locking and structure. It's not > exactly what we'll be doing in FreeBSD, but it's not a too-bad example. Of > course Mach is a microkernel design, but just overlook that while you're > looking at the SMP related stuff. :-) > Early SMP versions of just about every SMP Unix OS I know of started out > being a single lock and became fine-grained in subsequant versions (in many > cases before the code was officially released). Yes. The simplest method of increasing granularity is to tier the locks as global mutexes (not fix that yet), and then "push down" the locks through th trap code into the system call layer. At that point, you are free to add locks to structures accessed as a result of an interrupt or exception (the only two ways, other than the trap, to get into the kernel), and then you can multithread the whole damn thing, one subsystem at a time. You break the trap lock into inferior locks, one per subsystem (ie: VFS), and then break that lock further to push down a call at a time in the given subsystem. There is not a whole lot of global state that we have to worry about, other than entrancy counting so that a lock and a total can be set for getting everyone out of a given seperable module (ie: one processor wants to unload NFS, but nother one is using it, etc.). You can deal with per processor resources vs. system resources vs. system-but-per-processor-allocable resources to reduce bus overhead for interprocessor synchronization later. The "biggie" in that regard is, of course, VM, at a page granularity. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606050010.RAA27773>