Re: Future of FreeBSD

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_at_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_at_softweyr.com