DragonFlyBSD interview
There's a decent 2-page interview with the guy behind DragonFlyBSD (Matthew Dillon) over at OSNews. DragonFly is something I've been trying to keep an eye on for awhile, and seems to hold a lot of promise.
If you haven't followed, the BSDs (freeBSD, netBSD, and kinda/sorta Apples' Darwin) have had serious scalability and threading issues for a long while and a lot of effort lately has been going into fixing it (The same has gone on in Linux, but earlier). IE, traditionally the BSDs haven't been very efficient with heavily threaded code and weren't the best at scaling with dual-CPU systems, let alone quad+.
The direction freeBSD went in v5 didn't jive well with Dillon, so he forked the code at v4.x and is trying to go in a very different direction. freeBSD 5 is using a hardcore fine-grained mutex model, which adds a lot of complexity and can be difficult to keep sane... so theoretically, the DragonFly implementation should be much cleaner (IE, easier to debug & build upon). Theoretically. I think.
It's a little confusing, as it doesn't seem to necessarily deal with userland threads... A lot of the sweetness of the deal seems to be a way of lessening the impact of CPU-hopping. I'm pretty sure most systems have a form of CPU-affinity: if possible, the OS tries to keep a thread on the same processor, and doesn't bounce it between them. At the same time, it's trying to keep the load spread out evenly over the CPUs, so threads can get bounced between them.
IE, there is a thread that is playing the MP3s that you are listening to. Because it is a preemptive-multitasking OS, at the end of that threads time slice the OS pulls it off the CPU, and gives another thread some time to run. Then when it goes to give your MP3 thread more time on the CPU, if you have a dual-CPU system it has to decide which one to throw it onto... ideally, it gets thrown onto the CPU it was just on, and ideally that CPU still has some of what it needs to work with in its cache. If it got thrown onto the 2nd CPU, whatever data held in the 1st CPUs' cache is worthless and you have just potentially lost some performance.
DragonFly is supposed to be much better at this, as well as some other nifty things like working on a heavily threaded network stack which then gets replicated across the CPUs and never get bounced, etc. There's also some cool stuff at the filesystem level that should make package management a lot easier and avoid versioning problems (variant symlinks). Theoretically. I think.
Posted by drunkenbatmanMarch 15, 2004, at 12:52 AM
