Linked by evilsjg on Wed 16th Nov 2011 00:17 UTC
BSD and Darwin derivatives The DragonFly BSD project has recently decided to hold off on the 2.12 release to address a couple of long-standing issues. Some of the disruptive work done to address these issues has also resulted in the MP Token (giant kernel lock) and other major contention points being finally pushed out of the way of all critical paths. The result?
Thread beginning with comment 497299
To read all comments associated with this story, please click here.
Nice to see...
by madcrow on Wed 16th Nov 2011 01:28 UTC
madcrow
Member since:
2006-03-13

When Dragonfly originally forked from FreeBSD, it was mainly about SMP stuff. The Dragonfly faction felt that FreeBSD was choosing the wrong approach towards implementing good SMP support. When it became clear that FreeBSD's approach may actually have been the "right" one, Dragonfly refocused on doing other things like implementing microkernel-style features, a ZFS-like file system and other fun hacks. That's its been able to fix its SMP problems while also progressing on these other tasks is really a pleasant surprise.

Reply Score: 5

RE: Nice to see...
by Lazarus on Wed 16th Nov 2011 09:36 in reply to "Nice to see..."
Lazarus Member since:
2005-08-10

When it became clear that FreeBSD's approach may actually have been the "right" one


Not exactly. It wasn't a thought that the direction FreeBSD took to implement MP scaling wouldn't work or even work well, as it was in fact essentially a tried and true approach (fine-grained data locking).

Matt's problem with it was that he thought it would take more people and time and testing to make correct, and in the long run be more work to maintain due to the complexity involved. So From the get-go, DragonFly was reworked to support lockless algorithms and would do as much work on a per-CPU basis as possible. Kind of a `share as little as possible` approach, and ask your neighbours for help as needed.

DragonFly took so long to get to this point of scaling well in MP systems because very early on, Matt decided he wanted his BSD to implement SSI clustering, and being only one person in a small group of developers would then go on to implement the major bits of his dream, each of which was a fair sized project in themselves.

Hammer being an example.

Although MP work has long seemed to be more back-burner work for Dillon, he was always clear that he was more interested in exploring ways to enable multi-processor/multi-core scaling such that mere mortal devs could jump into the code and understand how it all worked and be able to fix it should that be required.

One final interesting thing to note, is that some of the ideas employed by DragonFly to implement MP scaling are also employed in Linux and FreeBSD as a means of further improving their scaling by removing some of their fine-grained locks.

And of course DragonFly itself uses a locking strategy vaguely similar to FreeBSD for its device drivers. Being a small project, this eases porting, and allows the DF devs more time to do more general work on DF itself.

Reply Parent Score: 4