Date: Sun, 18 Apr 2004 20:29:47 -0700 From: Wes Peters <wes@softweyr.com> To: freebsd-current@freebsd.org Cc: Robert Downes <nullentropy@lineone.net> Subject: Re: Future of FreeBSD Message-ID: <200404182029.47873.wes@softweyr.com> In-Reply-To: <4078F8EA.7090802@lineone.net> References: <8501.1081595369@critter.freebsd.dk> <4078F8EA.7090802@lineone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 11 April 2004 00:51, Robert Downes wrote:
> On your site, you talk about what you hope to achieve if you reach the
> required funding level.
>
> Could you, for those such as myself, explain in
> 'I'm-a-web-dev-and-I-call-myself-a-tech-guy-the-damn-cheek' terms
> (that's one step above layman's terms) what some of the infrastructure
> improvements mean.
>
> Such as: what is the "Giant" lock?
In FreeBSD 3.x and 4.x, the SMP code allows user processes to run, 1 per
cpu, without contention for resources. This is only true when they are
running in "user mode", i.e. NOT making any kernel calls.
Inside the kernel, in order to make sure critical data structures get
updated atomically (read that as "all at once" if you don't speek geek), we
put a "lock" around them. Whoever has the lock is allowed to read and
write the data structure, and everyone who is waiting for the lock has to
continue to wait until the lock holder gives up the lock. This protects us
against the case where I read a value, do some calculations, and then
change the value. Other threads of execution cannot even safely read the
value if I am going to change it.
The simplified version of SMP in FreeBSD 3-4 has one lock, referred to as
the Big Giant Lock, or BGL, or just Giant. This means that any process
that makes a system call* has to take the Giant lock, or wait for it to be
released. This means the SMP goodness is not shared among processes that
do a lot of I/O -- web and ftp servers, for example -- which are really the
sweet spot of the FreeBSD server userbase.
The development thrust of FreeBSD 5 is to develop fine-grained SMP. This
means instead of one Big Giant Lock, there are more locks, which protect
individual data structures, or groups of data structures as subsystems.
This allows multiple processes to be executing kernel code simultaneously,
so long as they're not trying to execute exactly the same kernel code at
the same instant.
The advantages of this finer-grained locking is to get more parallelism in
the kernel as well. Consider a web server, where the basic job is read a
request from a socket, then send the contents of one or more files in
return. If you have two or more clients attached, and multiple processes
to serve those clients, each process can be attempting to read from the
network, write to the network, or read from the disk. Instead of one
process reading from a network socket while all the other processes wait
for it, you have one process that can complete all of the socket read right
down to the critical data structures, locking only the socket it is reading
from, while another is doing disk reads, locking only the file descriptor
it is using. (Both have to, at some time, lock the global list of sockets
and file descriptors, but only when creating or freeing these resources,
see?)
At this point in time, a few major subsystems have been removed completely
from Giant, with their own subsystem or data structure locks. Other
systems, subsystems, or even just drivers are still protected by Giant.
Understanding locking as a concept is not all that difficult. Any good
operating system textbook, or basic computer science textbook, will cover
the concept adequately. I'll go out on a limb here and recommend the uC/OS
II book as an excellent reference for both what locks do and a simple,
embraceable implmentation.
If you want to get started on "lock pushdown" in FreeBSD, a classic "Junior
Kernel Hacker" task, I'll refer you to John Baldwin <jhb@freebsd.org> for
marching orders. There are a large number of such tasks that essentially
require you to find another similar driver that has already been
de-Giantified, identify the critical data structures in the driver of
interest, and lock in a manner similar to the known good driver, then test
test test.
* This is the simplified explanation. There are some system calls that
don't have to be locked. The details aren't important to anyone who
doesn't already understand locking. ;^)
> (I have read the section in your 'really long version', but, well... I'm
> a web-dev. I can write you a nice, standards-compliant website, but I
> don't have a clue what all the serious terms in your document mean. I
> did teach myself C when I was fourteen, but found little use for it at
> school, and it rusted away.)
>
> Just a few paragraphs on the current problems and potential results
> would be very interesting.
--
Where am I, and what am I doing in this handbasket?
Wes Peters wes@softweyr.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404182029.47873.wes>