posted by Eugenia Loli on Mon 8th Oct 2001 16:15 UTC

"Matt Dillon, VM and kernel FreeBSD team, Part III"
5. How do you feel that Linux got most of the attention the last couple of years, and it was able to move a bit faster to the desktop arena? Is the Desktop market interest at all the FreeBSD people?

Matt Dillon: I find it to be an interesting exercise in social engineering, economics, and psychology. Oh, you want to know what I *really* think?

I think biggest winner here is open-source. A great deal of what people label as 'Linux' isn't actually Linux. It's open-source that compiles just as easily on FreeBSD (*without* linux emulation) as it does on Linux. Take GNOME and KDE for example. No linux emulation necessary there! The areas where FreeBSD has problems are almost entirely relegated to commercial binary-only distributions. Now, that said, Linux is certainly the largest driver of interest that leads to the development of many of these projects. I don't think we would have GNOME or KDE without Linux. As a driver of interest Linux has earned its place at the top of heap.

In regards to the desktop... well, I'm not sure exactly what you are asking. Both Linux and FreeBSD are in the same boat there... the only way to drive desktop acceptance is to ship machines pre-installed with the OS (whatever OS) and preconfigured with a desktop so when you turn the thing on, you are ready to rock. The only way to do that is for the PC vendors to pre-install Linux (or FreeBSD, or whatever).

Other then that common issue, there really is no difference between FreeBSD and Linux in regards to the desktop. Oh, we could integrate the sound a little better and it would be nice to get a native OpenGL implementation working, but everything else is already there, because both platforms are running the same GUI software.

6. Please explain to us what SMPng (next-generation symmetric multi-processing) and KSE (kernel scheduler entities) are, which are features to be found on the BSD-5-Current.

Matt Dillon: SMPng is FreeBSD's fine-grained mutex, interrupt threading, and Giant-removal implementation. Potentially kernel pre-emption is also part of the equation but the jury is still out on that. The purpose is to be able to have several mainline processes and/or interrupts operating in kernel mode simultaniously. This is the primary scaleability issue in any SMP system. The work being done here is roughly compareable to the SMP work being done in Linux. Linux is about a year ahead of us but both Linux and the BSDs have a great deal of work to do to catch up with Solaris.

KSE is a totally new (but old idea) way of implementing userland threads. The idea here is two fold: (1) to remove any requirement that userland code understand which system calls might block and which system calls might not block. (2) to do all primary thread scheduling and switching in userland, where any given cpu can switch between threads with approximately the same overhead as a userland subroutine call.

With KSEs if a userland process makes a system call which blocks, the kernel will detach the kernel context (which is now blocked) and return directly to the user mode scheduler using an 'upcall'. The userland scheduler can then immediately switch to another thread. Another system call will be given a new, fresh, KSE to play with. The blocked kernel context runs completely asynchronously from the userland process until it finishes and can potentially run concurrently with other detached KSEs for the same process. When a KSE completes the kernel notifies the userland scheduler allowing the userland scheduler to reschedule the 'blocked' thread which is now 'returning' from the system call that originally blocked.

The essential difference between KSEs and both select/kqueue-based threads and rfork based threads is that with KSEs you get all the parallelism of the SMP box and all the power of a userland-only context switch between threads (read: *very* fast switch times) without *any* of the kernel overhead. A program can literally be running thousands of threads with no significant kernel overhead. Only blocked system calls eat kernel resources. In addition to this, we can manage kernel resources in the face of thousands of threads by limiting the 'pool' of KSEs we assign to any given process or user or whatever. So if 500 of those 1000 threads block in a syscall we just get a little less cpu-efficient and don't blow out kernel memory.

Currently FreeBSD can use both select/kqueue and rfork (linux-style) threading. KSEs bring us to the next level.

Table of contents
  1. "Matt Dillon, VM and kernel FreeBSD team, Part I"
  2. "Matt Dillon, VM and kernel FreeBSD team, Part II"
  3. "Matt Dillon, VM and kernel FreeBSD team, Part III"
  4. "Matt Dillon, VM and kernel FreeBSD team, Part IV"
  5. "Itojun, NetBSD Core Team"
  6. "Theo de Raadt, OpenBSD Founder"
e p (0)    27 Comment(s)

Technology White Papers

See More