Date: Tue, 8 Jun 2004 16:59:06 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-doc@FreeBSD.org Subject: Re: Fwd: Re: RFC: additions to the Glossary Message-ID: <200406081659.06684.jhb@FreeBSD.org> In-Reply-To: <p0620010abceb7a5479be@[129.85.219.160]> References: <p0620010abceb7a5479be@[129.85.219.160]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 08 June 2004 10:17 am, Chris Pepper wrote: > >From: Ken Smith <kensmith@cse.Buffalo.EDU> > >To: George Keramidas <keramida@ceid.upatras.gr> > >Cc: Mark Linimon <linimon@lonesome.com> > >Cc: freebsd-doc@freebsd.org > >Subject: Re: RFC: additions to the Glossary > > > >On Tue, Jun 08, 2004 at 12:08:30PM +0300, George Keramidas wrote: > > > On 2004-06-08 03:07, Mark Linimon <linimon@lonesome.com> wrote: > > > > > > An explanation of what "coarse" and "fine-grained" locking is, is > >> > >> probably going to be useful too. > > > >I don't know at what level to trim what follows, it's too long to put > >the whole thing in the entry. But this is a bit of the history behind > >the need for this entry. If any of it is useful cool... > > > > As originally designed the UNIX kernel was not designed with > > multiple processors per machine in mind. If data structures > > inside the kernel were accessed at the same time by code running > > on two (or more) processors the data structures could become > > corrupted (for example linked lists are notorious for this). > > During the early stages of porting &os; to computers with > > multiple processors the developers cheated. It was set up > > so that only one processor could possibly be executing code > > inside the kernel at any point in time. This was done by > > creating a mutex named Giant, and any processor that needed > > to enter the kernel needed to obtain the Giant mutex before > > it could enter the kernel (and it had to release Giant when > > done inside the kernel). This allows user-level processes to > > run on different processors at the same time but avoids the > > need to "fix" the kernel's data structure issues all at once. > > Once this method of operation (known as Asymmetric Multiprocessing > > or Coarse-grained Multiprocessing) was working the Developers > > started to work on allowing multiple processors to execute code > > inside the kernel at the same time by creating mutexes that > > protect individual data structures. As time goes on more and > > more sensitive data structures are protected by their own > > mutexes. More and more system calls (the main entry points > > into the kernel) can now proceed without needing to obtain > > the Giant mutex, and only stop if they need a mutex protecting > > a specific data structure they require. This is known as > > Symmetric Multiprocessing or fine-grained Multiprocessing. Work > > is still progressing in certain areas of the kernel so there are > > still cases where the Giant mutex is still required. > > I'd change "cheated" to "took a short cut" -- cheated implies > that it wasn't a valid or reliable solution. Optimizing release > timeframe at the cost of SMP efficiency was obviously considered > appropriate when the decision was made, but this is no longer the > case. I'm not sure the use of 'Symmetric' vs. 'Asymmetric' is correct, either, but I'd need to recheck my Schimmel SMP book. Also, Giant is not a hold over from previous BSD releases. FreeBSD 3.x and 4.x used a single mutual exclusion lock (not the same as the Giant mutex in 5.x) around most of the kernel (a few places like fast interrupt handlers have their own spin locks). FreeBSD 5 has a sleep mutex called 'Giant' that protects most of the kernel. FreeBSD <= 3.x and BSD in general do not have mutexes at all but use spl + lockmgr locks. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406081659.06684.jhb>