For those of you who build custom kernels, the if_sl, if_ppp, and if_faith devices are now built as modules, not in the kernel. This means you can remove references to them in your custom kernel config – if you have one.
As part of a larger conversation about security measures, NX bit capability was added to DragonFly. You can turn it on or off, and it’s off by default so it doesn’t cause any surprises. As the first link in this post points out, your installed third-party software is more of a security issue than processor features, in any case.
In my ongoing quest to actually catch up to all the DragonFly commits recently, here’s a recent update to machdep.cpu_idle_hlt. Set this to affect power usage. I’m linking to this list of the different settings because, like RAID levels, nobody can or should remember every one.
Continuing my catchup on recent commits, there’s now a ‘version 7’ internal to HAMMER 1. It changes the CRC code to a faster version, but since this instruction isn’t used (yet), there’s no real world impact. Remember this for next time you want to run ‘hammer version-upgrade’.
Did you know there’s a randread utility on DragonFly that will report on disk performance? Well, you do now. The very terse comment in the source code will tell you how to compile it and the arguments.
Yes, I know we just released 4.8. This is a rollup release, capturing everything that was committed to the 4.6 branch after 4.6.1 and before 4.8 came out. If you are going to upgrade, it’s worth it to go to 4.8, but this way there’s a clean final version in the 4.6 branch.
(Hat tip to Sascha Wildner for reminding me to do this.)
I am late in mentioning this, because it was added just before the DragonFly 4.8 branch: there’s a new ‘efisetup(8)‘ script added to DragonFly. Use to to perform a complete a UEFI-bootable installation to a given disk.
I always attributed speed issues to writing transaction history, but: Matthew Dillon discovered HAMMER was repeating itself when writing to disk. Fixing that issue doubled write speed. This fix is in 4.6 and the upcoming release.
The longstanding practice is to load kernel modules in loader.conf, as early as possible. That’s good, for anything that needs them.
However, that also can be bad. Your machine can be unbootable if there’s a problem with a module or loader.conf is messed up, since that file is read long before the startup process finishes. Enter the new alternative: modules can be loaded in rc.conf, and the only loader.conf modules needed are those required by / to mount.
Matthew Dillon has been doing a significant amount of work on cache lines, and I haven’t been linking to it because it’s hard to point at single commits with such a technical subject. However, he’s summarized it all, along with news on NUMA handling and vkernel improvements.
Matthew Dillon moved some locks and exec() performance jumped up significantly – 50% or more. This is a single system call, so I don’t know how much translates through to real performance change, but it’s interesting to see.
Rimvydas Jasinskas posted an extended description of what’s happening with dports. There’s a significant xorg reformatting coming in ports, which is going to be absorbed into dports, but it may take some time. There’s also an odd loss of commit rights for John Marino, who commits (frequently!) to both DragonFly and FreeBSD. (His followup) This all translates to some upcoming transition time for dports to accommodate these changes.
Note that if you are using dports binaries, especially on DragonFly 4.6 release, this won’t really affect you; the way dports is set up, binary sets always work. It is interesting to hear about future work, in any case.
The vkernel(7) code has been going through a lot of changes, and instead of linking to the many smaller commits, I’ll point at Matthew Dillon’s latest change since it’s detailed. What’s the performance difference? I don’t know yet if this is for performance or for stability.
The ncv(4), nsp(4), and stg(4) drivers are now removed from DragonFly. So is the portal file system. Also, though not a removal, vm.swapcache.use_chflags now defaults to 0. Does this affect you? Almost certainly not! I feel compelled to point it out, though, just in case there’s that one person who didn’t want a surprise.
If you are on DragonFly -master, now is a good time to update. Matthew Dillon has been changing how DragonFly handles locking and memory use, with differences in the vmstat structure and page coloring, some memory settings, and many other locking changes. I am only linking to a few examples. If you don’t want to dig through those links for performance numbers, he summarized his changes and their effects in a post to users@.
That’s Non-Uniform Memory Access, to disambiguate. Matthew Dillon’s changing how memory is allocated in DragonFly. NUMA is been a long-discussed and complex topic for a long time, so I will point at the initial commits and call it “a developing situation”.
If you are using DragonFly under Hyper-V, Sepherosa Ziehau’s been making additional commits to improve compatibility. What’s it like? I don’t know; I haven’t tried Hyper-V yet.
The version of binutils used in DragonFly is now 2.27 by default. This will make the most difference to you if you want to work with Link Time Optimization.
If you were running DragonFly 4.7, for a short period you may have had trouble with shutting down, because of an ACPI bug. It’s fixed now. It’s actually been fixed for two weeks, but I’m going back and clearing things I hadn’t had a chance to post, since we are in the Christmas-New Years lull time.
Don’t get too excited yet – clang import hasn’t happened. However, I want to draw attention to Rimvydas Jasinskas’ changes to alternate compiler handling, which would be for importing clang. His commit message goes into some of the rather thorny problems of transitioning between compilers and releases.