Date: Mon, 3 Jul 2000 22:25:32 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Greg Lehey <grog@lemis.com> Cc: Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <Pine.SUN.3.91.1000703220209.29911A@pcnet1.pcnet.com> In-Reply-To: <20000703200039.H62680@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Jul 2000, Greg Lehey wrote: > On Monday, 3 July 2000 at 6:23:28 -0400, Daniel Eischen wrote: > > Well if you are considering spinning for a bit of time on a held > > mutex (which you seem to advocate?), then why not wake everyone? > > Because it doesn't buy us anything. You only have to take the sleep queue lock once to wake all the waiting threads/processes instead of N times if you have N waiting threads. You only have to take the scheduling queue lock once to place the waiting threads on the scheduling queue. I'm not advocating doing this (right now) in FreeBSD. But this seems like a potential optimization we could possibly do in the future. But in order to do this, we need to make sure that the time mutexes are held is very short. My only suggestion was that we comment those sections of code that can hold mutexes for long periods of time or use a different naming convention for those mutexes. > > If mutexes are held for very short periods of time and you don't > > often have a thundering herd problem, > > That's an assumption. So far we have *never* had a thundering herd, > because the code don't work yet. I wouldn't call the above an assumption. I'm not assuming anything. It is predicated with an "if". If we would/do have a thundering herd problem then I sure wouldn't want to wake_all(). > > > then waking everyone is an optimization since you only have to take > > the scheduling lock once. > > No. If I understand things correctly, each process would need to get > the schedlock, and only one process can get the mutex. Why wake the > rest? What do you want them to do? This applies even in the case of > a counting semaphore (of which our "mutex" is a special case), since > if any slots are available, the process wouldn't be sleeping. No each process would be placed in the run queue with wake_all() semantics. Plus you would only have to take the sleep queue lock once too. Waking processes doesn't mean that they will run immediately. The first process to run will hopefully take the mutex and release it is a timely manner so that by the time the next process runs it can take the mutex uncontested. -- Dan Eischen 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?Pine.SUN.3.91.1000703220209.29911A>