RFC: additions to the Glossary

[Ken Smith]

On Tue, Jun 08, 2004 at 12:08:30PM +0300, George Keramidas wrote:
> On 2004-06-08 03:07, Mark Linimon <linimon at 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 at cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |