DrunkenBlog

The BSDs are growing up

I was reading through an Oreilly interview on the improved multiprocessing in FreeBSD, and and it sparked the memory of a conversation I had several days ago where I said: "I'm interested in Linux, but I love the BSDs".

The person was curious as to why I'd say that, and I actually had to think about it for a few seconds. I dig Linux in general, and use it. There are a whole bunch of places where I'd pick using Linux over a BSD. There just isn't quite that same... affectionate warm spot in my head.

Defining that warm spot can be a little difficult, but I think it mostly comes down to the same quality you get when looking at a child's eyes. Their approach to the world is just so... straightforward. Children can be manipulative, they can have an agenda, and they can be the most manipulative little bastards in the world, but how they approach that agenda is usually so straightforward that it's hard not to give them points.

That's pretty much where my soft spot for the BSDs lies. The Linux kernel has been... growing up... in terms of how it handles things. Windows is already there, and so is OS X. I wouldn't call any of these products really mature yet, but they've certainly been entering a type of adolescence, and all the growing pains they engender. While all this was going on, the BSDs have just been trucking away at their various focuses, but in most cases moving sideways. This isn't to say they haven't made major progress, just that in most cases the progress hasn't been especially broad.

Pages could be spent on the problems the BSDs have had with getting in new blood, the makeup of their groups, the sheer politics surrounding everything... but that stuff bores me. The big gap for most of them has been real, kick-ass multi-CPU support. If you'll remember, the BSDs are a little different from Linux in that the various distributions are so finely focused. You see this in Linux too, but not to the Nth degree like you do with the BSDs, which then all cross-pollinate if someone hits on something cool.

Some of the BSDs are focused on having it on as many platforms as possible (NetBSD), others are focused on being as absolutely secure as possible, and others are more general purpose. Either way, the multiprocessing on all of them has kind of sucked, and in some has been non-existent until recently. An example of this would be OpenBSD, whose focus is on security. It's got an incredible track record in terms of security, but until the last release had basically zero SMP support. Seriously. With v3.6 OpenBSD has basic SMP support, something from the BSD 4.4 world, but it's really only available on i386 (x86) and AMD64 systems.

With the move to FreeBSD v5, the FreeBSD folks were working hard to change that in a big way and bring SMP into the modern age on the platform. Some thought they were moving in a direction with their SMP support that they weren't happy with, which was something I fumbled through in a prior post about DragonFlyBSD.

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.

I go on to try to give a real-world example of where this can be a problem and how DragonFly is supposed to be ease things. The key word in that sentence is try. I have a feeling it's probably a pretty poor way to explain the benefits, but there's little real hard data out there. That situation has gotten a little better. If you're curious, here's a list of DrangonFlyBSD interviews I've come across:

• NewsForge interview
• Slashnet IRC log
• OSNews Interview
• Oreilly.com Interview

There's certainly something to be said for what Dillon is doing, as the current FreeBSD model, while greatly improved, doesn't really going into the advanced areas like CPU-affinity. At the same time, whether it'll be that huge of a difference, or at least enough to make people sorry they didn't go that route is up for debate. However, that's his prerogative.

The long and short of it is that the BSDs are having to 'grow up' in how they handle things, becoming much less straightforward, and I think it's a fascinating period. By straightforward, I just mean that the system is having to take much more into consideration while doing what it does. A generic SMP system suited for servers might kick ass at that, but then start to have real problems when you are targeting the Desktop.

What works for both of those in a generic way might start to really choke when you try to scale past eight CPUs. It's an exciting time for the BSDs in a way, although at this point I've been wondering what will really come from it in terms of adoption or other areas. The other thing I've found to be interesting is that because they don't have some of the pressing concerns of say, Linux, they're able to be much more experimental in the directions they take in some ways.

Many of the things they're trying are "Well, we don't really know if it'll make that big of a difference... but hey, we have the luxury to try it out". Which isn't to say there aren't any users BSD users, or that say, OpenBSD users aren't slavering over serious MP support, it's just that the needs aren't quite so pressing and they're not having to make as many people happy.

 Posted by drunkenbatman
    January 23, 2005, at 06:54 PM