Date: Tue, 8 Jun 2004 06:28:53 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: George Keramidas <keramida@ceid.upatras.gr> Cc: freebsd-doc@freebsd.org Subject: Re: RFC: additions to the Glossary Message-ID: <20040608102853.GE4224@electra.cse.Buffalo.EDU> In-Reply-To: <20040608090830.GA2270@orion.daedalusnetworks.priv> References: <200406080307.31235.linimon@lonesome.com> <20040608090830.GA2270@orion.daedalusnetworks.priv>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> > This patch adds definitions for Giant, LOR, NDISulator, OBE, pointyhat,
> > and Project Evil, and expands the entry for BSD.
> >
> > Unless anyone objects, I would like to go ahead and commit these changes.
>
> I think they're great :-)
>
> : + <glossterm>Giant</glossterm>
> : + <glossdef>
> : + <para>The name of a kernel resource lock that protects a large
> : + set of kernel resources. It is an unwanted remnant of much
> : + earlier <acronym>BSD</acronym> kernels which used very coarse
> : + locking mechanisms (for instance, if any process was in the
> : + network stack, every other process was locked out). While
> : + this was adequate in the days where a machine might have only
> : + a few dozen processes, one networking card, and certainly only
> : + one processor, in current times it is an unacceptable
> : + performance bottleneck. &os; developers are actively working
> : + on replacing every occurrence with fine-grained locks that
> : + protect individual resources.</para>
>
> Cool, this is probably a much needed entry, since a lot of people are
> going to ask what "Giant" is, once they see it referenced in a commit
> log or an old, archived mail message. I don't like to sound like I'm
> knit picking too much, but perhaps "every occurence with..." could be
> "every use of Giant with..."?
>
> 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.
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040608102853.GE4224>