Date: Mon, 3 Jul 2000 22:08:24 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Greg Lehey <grog@lemis.com> Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, Daniel Eischen <eischen@vigrid.com>, Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000703220823.Z25571@fw.wintelcom.net> In-Reply-To: <20000704083822.A65029@wantadilla.lemis.com>; from grog@lemis.com on Tue, Jul 04, 2000 at 08:38:22AM %2B0930 References: <20000703114535.T39024@wantadilla.lemis.com> <Pine.SUN.3.91.1000703060948.5216A-100000@pcnet1.pcnet.com> <20000703200039.H62680@wantadilla.lemis.com> <3960A971.982DDF07@vangelderen.org> <20000704083822.A65029@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Greg Lehey <grog@lemis.com> [000703 16:10] wrote: > > That's my reading of Sun's claims in Solaris and given that they > > have a little more experience with this kind of thing I'm inclined > > to believe them until I see facts stating the contrary. > > Sun's problem with Solaris is non-obvious, and may not bite us. > > I think we should hold off with this kind of discussion for the while. > Everything I can see suggests that it's crazy to wake all processes. > If we find that we run into race conditions which we can only solve > with wake_all, though, we'll compare the effort in fixing them with > the (undoubted) performance degradation caused by waking them all. The idea is that for spin or spin-then-sleep mutexes (very short hold time) is that since you won't have as many processes as cpus contending (and when you do it's ok) that the mutual exclusion is so short lived that by the time the next 'thundering' process is actually given the CPU, the likelyhood is that other processes have already aquired _and_ released the spinlock making it more than likely that the reasource is free. The idea is that the a quantum is actually so great that there's little chance of one of the wake_all processes colliding on the lock. By effectively you gain a whole lot because you avoid having to grab sched-mutex on each aquire/release and you also reduce the cache cost of wakeups because it's likely that only once kernel context will wind its way down the sleep queue. What sort of interesting is that doing it one way or the other is so similar that in reality the initial implementation doesn't matter, switching from one to the other will be trivial at most, the importance lies in getting one implementation done. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000703220823.Z25571>