DragonFly users List (threaded) for 2007-08
Re: Kerneltrap interview available
:> Jeremy did another interview of me in Kernel Trap, here's the URL:
:Heh, judging by all the anonymous comments, somebody really has a bee in
:their pants over the whole SMP thing. I better stop feeding those trolls.
:Dare I ask for the cold hard truth about the state of SMP on DragonFly?
It's not actually that bad. The main paths that need to be locked up
are the I/O path (all the way through to the filesystem code, including
the buffer cache) and the VM path (which is less important). A
per-process spinlock is also needed to handle MP safe operations in
the presence of multiple threads (LWPs or rforked processes).
Just about everything else is already coded MP safe, but still make
general procedure calls into the kernel which are not yet coded MP safe.
This is basically where the networking code is... MP safe except for
mbuf statistics and mbuf dup/free paths. Network drivers are serialized
within themselves but still make kernel calls which are not MP safe.
Protocol threads themselves are coded MP safe but do the same thing (make
general calls that aren't).
For userland applications we need to switch from libc_r to libthread_xu,
which means figuring out what still needs to be done in that library to
make it work properly with major applications. KDE, Firefox, etc.
There isn't a whole lot left that needs to be done there, its just a
matter of tracking down the remaining issues. We probably need to
implement the various posix scheduling methodologies, too.
SMP isn't on my priority list but that shouldn't stop anyone who wants
to work on it.