Merry Christmas, here’s an incredibly involved bugfix

There’s been a rare segfault present in DragonFly for quite some time.  It’s been difficult to reproduce, and the 2.12 release due some months ago was held up specifically to fix it.  Matthew Dillon was, after many days (months?) of work, able to replicate it reliably and eventually find a way around what appears to be a new AMD-specific bug.  Read his very detailed explanation of what he did to get to this point.

VFS accounting benchmarks

Francois Tigeot benchmarked his accounting work with blogbench, and posted a PDF with the results.  Dmitrij D. Czarkoff made a simpler graph, which can be used to draw the conclusion: blogbench didn’t work well for estimating the impact of VFS accounting. If you want to try accounting yourself, put vfs.accounting_enabled="1" in your /boot/loader.conf.

(The normal DragonFly mailarchive isn’t updating because it feeds from DragonFly NNTP, and that’s not updating, so I’m using Gmane for post links.)

Parallelized buildworld now possible

Buildworlds are now much faster, because they can run themselves in parallel.  Invoke it using the -j option to make.  Matthew Dillon saw a 25% reduction in time when using ‘make -j 12 buildworld’ on a 4-core system.  You may need to manually update xinstall and mkdir:

        cd /usr/src/usr.bin/xinstall
        make clean; make obj; make all install
        cd /usr/src/bin/mkdir
        make clean; make obj; make all install

It’ll also use more memory than a non-parallel build, but heck, that’s cheap these days.

An unexpected way to do strlen()

The general rule of thumb is that if you have a function written in an interpreted language (Perl, Python, etc.), it’ll be faster in C.  If you need it faster than that, you go to assembly.  Prepare to have your world rocked: Venkatesh Srinivas found that strlen() in libc was actually slower written in assembly than in C.  His commit message has numbers to back that up.