Date: Wed, 28 Jun 2000 13:00:31 +1000 From: Greg Lehey <grog@lemis.com> To: Daniel Eischen <eischen@vigrid.com> Cc: Jason Evans <jasone@canonware.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000628130031.B1760@sydney.worldwide.lemis.com> In-Reply-To: <Pine.SUN.3.91.1000625091445.2784A-100000@pcnet1.pcnet.com>; from eischen@vigrid.com on Sun, Jun 25, 2000 at 09:58:27AM -0400 References: <20000624235605.D8965@blitz.canonware.com> <Pine.SUN.3.91.1000625091445.2784A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 25 June 2000 at 9:58:27 -0400, Daniel Eischen wrote: > On 24 Jun 2000, Jason Evans wrote: >> 3. The BSD/OS solution. >> >> - The BGL remains, but becomes increasingly meaningless. In particular, >> it is not always necessary to obtain it in order to enter the kernel. >> >> - Instead the system protects shared data structures with mutexes. >> These mutexes replace calls to tsleep() when waiting on shared >> resources (the involuntary process synchronization mentioned above). >> In contrast to traditional UNIX, mutexes will be used much more >> frequently in order to protect data structures which were previously >> implicitly protected by the non-preemptive nature of the kernel. This >> mechanism will replace calls to tsleep() for involuntary context >> switches. >> >> Compared with the use of tsleep(), mutexes have a number of >> advantages: >> >> - Each mutex has its own wait (sleep) queue. When a process releases >> a mutex, it automatically schedules the next process waiting on the >> queue. This is more efficient than searching a possibly very long, >> linear sleep queue. It also avoids the flooding when multiple >> processes get scheduled, and most of them have to go back to sleep >> again. >> >> - Mutexes can be a combination of spin and sleep mutexes: for a >> resource which may be held only for a very short period of time, >> even the overhead of sleeping and rescheduling may be higher than >> waiting in a tight loop. A spin/sleep lock might first wait in a >> tight loop for 2 microseconds and then sleep if the lock is still >> not available at that time. This is an issue which Sun has >> investigated in great detail with Solaris. BSDi has not pursued >> this yet, though the BSD/OS threading primitives make this an easy >> extention to add. It's possibly an area for us to investigate once >> the system is up and limping again. > > If anyone is interested... > > All high-level interrupts (levels 11-15, mostly PIO serial interrupts) > in Solaris use spin mutexes and don't use an interrupt thread. They > execute in the context of the thread that was currently running. All > other interrupts below level 11 (clock, network, disk, etc) use interrupt > threads. > > A Solaris (non-spinning) mutex will only spin while the owning thread is > running. Since BSDi mutexes have owners (correct me if I'm wrong), this > seems to be better than arbitrarily spinning. Mutexes only have owners when they're being held. But we won't spin for any length of time on a mutex; that's why we have a thread context for the interrupts. >> - BSD/OS also does not implement read/write locks, a thing that Linux >> has recently introduced. We didn't discuss this further, but the >> concepts are well understood, and it should be relatively simple to >> implement them if we find a need. > > Mutexes are only used in Solaris when they will be held for very small > amounts of time. Read/write locks and semaphores are used for all > other instances. While we are modifying the kernel to add mutexes, > it would probably be worthwhile to comment those sections of code > that could hold mutexes for something other than a very short period > of time. Or even use a different naming convention for those mutexes. Agreed, I don't like the terminology we seem to have settled on. From my way of thinking, a mutex is a spin lock, and a semaphore is a blocking lock. What we're talking about here are really semaphores, though it makes sense to spin a bit first before blocking in the case that the lock may be released quickly: it takes a fair amount of overhead to schedule, and if there's a good chance the lock will be available by the time we've scheduled, there's no point in blocking immediately. One of the things I want to do further down the line is to instrument some statistics on the semaphores^H^H^Hnmutexes so we can decide what kind we need where (and when). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000628130031.B1760>