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?

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.