If you’ve had odd behavior with node.js (which I have) on DragonFly, it may be fixed now.
Sascha Wildner has updated ACPICA in DragonFly to Intel’s version 20170629. This will be of most interest to those with newer motherboards, as it matches ACPI 6.2.
A recent commit from Matthew Dillon serves as a rough safety valve, making it harder to fork/chroot yourself to death.
Apparently there’s a missing dhclient feature in DragonFly needed to run on OpenStack. Matthew Dillon’s made a change to get it to work – though I can’t find the exact commit.
Version 1.13.1 of nginx now natively uses CPU affinity on DragonFly. This matches well with SO_REUSEPORT support; I suspect DragonFly is a fantastic place to run nginx at this point.
…And before you say, “It would be great if someone would put together benchmarks”, think instead, “I’m someone, and I could do it.”
Imre Vadasz added support for ADMA2 transfers in DragonFly. It doesn’t lead to a huge performance boost – yet. It can be turned on and off, but requires Intel chipsets.
Francois Tigeot has brought in the ‘apple_gmux’ driver. If you have a Macbook with both Intel and NVIDIA video hardware installed, this driver lets you switch to the Intel hardware, and I assume take advantage of DragonFly’s accelerated i915 driver.
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.