From owner-freebsd-smp Tue Jun 27 20: 0:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from front.linuxcare.com.au (linuxcare.com.au [203.29.91.49]) by hub.freebsd.org (Postfix) with ESMTP id 8682737B71D for ; Tue, 27 Jun 2000 20:00:36 -0700 (PDT) (envelope-from grog@sydney.worldwide.lemis.com) Received: from sydney.worldwide.lemis.com ([203.17.0.42]) by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA07171; Wed, 28 Jun 2000 13:00:32 +1000 X-Authentication-Warning: front.linuxcare.com.au: Host [203.17.0.42] claimed to be sydney.worldwide.lemis.com Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id NAA01876; Wed, 28 Jun 2000 13:00:31 +1000 (EST) (envelope-from grog) Date: Wed, 28 Jun 2000 13:00:31 +1000 From: Greg Lehey To: Daniel Eischen Cc: Jason Evans , smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000628130031.B1760@sydney.worldwide.lemis.com> References: <20000624235605.D8965@blitz.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from eischen@vigrid.com on Sun, Jun 25, 2000 at 09:58:27AM -0400 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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