FreeBSD 7, DragonFly's status

[Dmitri Nikulin]

Hi everyone, I've been busy so I haven't said anything here in a long
time, but reading about FreeBSD 7 has raised some thoughts.

I'm really interested to see that FreeBSD 7 in particular is becoming
a hybrid of its old self and DragonFly's kernel architecture concepts.
More subsystems like the scheduler and network stack are becoming CPU
localised in a DragonFly way, but not based on message passing quite
as much. Threading primitives are being optimized as well, improving
performance to a Linux level. The trend seems to be towards
modernizing and optimizing just as much as DragonFly, but still based
on the fine-grained locking model rather than a massive localised
parallelism model.

The benchmark at http://people.freebsd.org/~kris/scaling/os-mysql.png
(for the full presentation, see
http://www.freedomtc.com/pdf/7.0_Preview.pdf, that plot is on slide
17) indicates that FreeBSD 7 not only competes strongly with current
Linux performance and scalability, but that DragonFly has been beaten
even by NetBSD which came late to the SMP party.

I don't know if this benchmark has been discussed here, but out of
interest, is it just a couple of small optimisations or configuration
tweaks that need to be made for DragonFly to shine on such a
benchmark, or is DragonFly still in architecture work and not really
optimized? Is it just the giant lock grinding in the kernel?

At the risk of sounding like a troll, may I ask, if FreeBSD 7 has high
performance, high stability and remains reasonably clean and
maintainable, doesn't that partly invalidate the reasons DragonFly was
created? Being cleaner and more revolutionary doesn't count for much
if the product itself doesn't serve as a compelling alternative. Maybe
I'm just missing the point of DragonFly's development.

I can look back over everything that's come in to DragonFly, including
a lot of really great ideas with great implementations, but it still
doesn't seem to be nearly enough to satisfy an administrator selecting
an operating system for a new project or solution. Some items like
journalling and DragonFly-on-DragonFly virtualization were never
driven to their logical or even feature set conclusions, while de
facto standards like Xen support and even AMD64 are almost entirely
neglected. Again, at the risk of sounding like a troll, I'm gravely
concerned about the growth and survival of this brilliant project in
the face of increasing pressure from projects with much larger
developer communities and software ecosystems.

I look forward to being told I'm completely wrong and everything is
much better than it seems :)

Cheers
-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia