Posted on
Hammer2 status

This is a little old, but Matthew Dillon noted the status of his Hammer2 work a little while ago.  Some highlights: he’s intending Hammer2 to be usable on a single host by the time of the next DragonFly release (summer 2014), the Summer of Code project for compression has already been integrated, and he listed different parts of the work that may be interesting for anyone wanting to chip in.

Slightly related: Matt posted some Hammer2 comments on the DragonFly 3.6 release story on Slashdot that may be interesting.  Don’t bother reading the other comments; they’ll make your eyeballs bleed.

Posted on
DragonFly 3.6 released

The 3.6 release of DragonFly is available now.  I just put up those images last night, so if your favorite mirror doesn’t have it, give it a few hours.

For those updating from 3.4 to 3.6: there’s an ABI change, so you will have to upgrade all your packages.  If you’re using pkgsrc and ready to switch to dports, now’s the time.  If you already switched to dports on your 3.4 system, binary packages for 3.6 have already been built and you can use pkg to upgrade.

Also for upgrades from 3.4: You can pull the 3.6 source normally:

cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_3_6 origin/DragonFly_RELEASE_3_6
git checkout DragonFly_RELEASE_3_6

But there’s a slight change needed for the 3.4 to 3.6 transition: an extra reboot in the build process:

# make buildworld && make buildkernel && make installkernel && make installworld && reboot

# make upgrade

This is all noted in /usr/src/UPDATING and in the release notes, but I’m taking no chances.

Posted on
In Other BSDs for 2013/11/09

Not sure why, but there wasn’t a lot of things this week to pick out.

 

Posted on
Performance tuning

Matthew Dillon did some more performance tuning for DragonFly.  I’ll just pull a paragraph from the commit message, since that will have more impact than anything I say:

Improves fork/exec concurrency on monster of static binaries from 14200/sec to 55000/sec+. For dynamic binaries improve from around 2500/sec to 9000/sec or so (48 cores fork/exec’ing different dynamic binaries). For the same dynamic binary it’s more around 5000/sec or so.

“monster” is a 48-core machine used for testing.

Posted on
Discontented with contention? Be content.

Matthew Dillon wrote a roundup post summarizing all the changes he’s made to DragonFly to improve SMP performance in the last few weeks.  He’s removed almost all contention from DragonFly.  This means better performance, scaling upward depending on the number of processors.

‘monster’, the system that builds all 20,000 items in dports, can complete the run in 15 hours.  Compare this to the 2 weeks it used to take me to build the 12,000 packages in pkgsrc.  This is admittedly on different hardware and different packaging systems, but it gives a sense of the scale of the improvement.