Linked by Eugenia Loli on Thu 23rd Jun 2005 18:11 UTC
Original OSNews Interviews One of my popular articles shortly after I joined OSNews in 2001 proved to be "the big *BSD interview" and so it is only appropriate to end my serving at OSNews with a similar theme. Today we are very happy to host a Q&A with well-known FreeBSD developers John Baldwin, Robert Watson and Scott Long. We discuss about FreeBSD 6 and its new features, the competition, TrustedBSD, Darwin etc.
Permalink for comment
To read all comments associated with this story, please click here.
RE: My hard hitting questions
by Robert Watson on Fri 24th Jun 2005 00:41 UTC

> I can't see how FreeBSD 6 will scale much better when NewBus, VM,
> Buffer Cache, VFS, Processes and Thread Operations, Scheduler, IPv4, IPv6
> and the Network stack are all under Giant Lock. At the moment, it seems
> that the project is getting the worst of both worlds, all the negatives of
> being under giant-lock and being multithreaded.

I think your comments may come from a mis-understanding about the process of removing Giant from the kernel, or at least, how this is illustrated in our SMPng development web page. Removing Giant is an incremental process, in which progressively fewer sections of the kernel run with Giant. With each release of FreeBSD as of 5.0, fewer and fewer sections are covered--in 5.3, for example, the "big deal" was that the vast majority of the network stack ran without Giant. The exceptions were largely in the form of "edge cases" in the stack, or less commonly used components in IPX/SPX. In FreeBSD 5.4, IPX/SPX ships without Giant over it. The developer-centric SMPng web page tracks "done" in the sense of 100% completeness, as it has centered on whether tasks remain to be done by developers so that developers can identify new work that must be done. So if something runs 95% of the time without Giant, the 5% being unusual configurations or rare cases (such as loading a network device driver), it will still be listed as "in progress".

Of the above subsystems, all run without Giant in the performance-centric paths and common cases. For example, the complete top-to-bottom I/O and name space paths for the UFS file system, but not, for example, the MSDOS file system.

Another interesting property of the Giant removal process is that as Giant falls over less and less of the system, contention on Giant is improved, improving performance for components of the kernel that remain under Giant. For example, if a device driver runs with Giant still, it will see lower contention in 6.x as it will no longer contend with Giant over the buffer cache, VFS name space, file system, etc, since it is no longer held there, resulting in lower latency in processing the disk interrupts.

In practice, all of the components you identified in your post, from the scheduler and threading code, to VFS/VM/buffer cache, to IPv4 and IPv6 network stacks, run without Giant. This means entirely Giant-free operation for our important network and file system loads, such as multi-threaded web server operation.