Sepherosa Ziehau has added a generic form of support for multiple transmit queues in DragonFly. This means less contention when transmitting. It’s not done; he has drivers to set up and as he said, it’s “step 1 of many“.
If you are on DragonFly 3.3, and you are running a kernel built after January 1st, there’s a bug in the way FP context is handled when the kernel supports AVX. (January 1st is when AVX support was committed.) Matthew Dillon has committed a fix and issued a note to update for everyone.
If you recall, Phoronix recently ran a bunch of benchmarks on DragonFly. One spot that didn’t look good was the “Himeno Poisson Pressure Solver”. I’m no closer to knowing what capability it actually tests other than itself, but Alex Hornung, Matt Dillon, and Venkatesh Srinivas figured out that cache coloring was the missing ingredient. DragonFly now scores the same as Linux.
Tangentially related, this cache coloring is happening in nmalloc, which is now used on 64-bit DragonFly systems. The previous one, dmalloc, had problems in long-running programs.
I’m not sure what IFQ stands for, but Sepherosa Ziehau’s added it. It appears to be based on an idea from Luigi Rizzo called ‘netmap‘. In this case, network packets are grouped together before being placed onto the network interface’s hardware queue. That means better packet per second performance without a corresponding increase in CPU usage, as Sepherosa Ziehau’s report lists, along with needed sysctls.
If you’re running DragonFly 3.3, make sure you perform a full buildworld and buildkernel when you next upgrade. Sascha Wildner is mentioning this as a cautionary note after experiencing issues when using quickkernel, after removing a number of syscalls. Once past that point, it should be safe to go back to quickworld/quickkernel.
Matthew Dillon turned off the machdep.pmap_mmu_optimize sysctl by default, since wider testing has found some bugs. It’s only on by default on DragonFly 3.3 systems, so there’s nothing to do if you’re on 3.2-release. The feature will come back after some bugfixing.
I knew about files like /etc/services, for common IP port usages, and /usr/share/zoneinfo, for time zones, but I didn’t know that DragonFly (along with other systems) keeps a list of agreed names for various human languages defined by ISO639 in /share/misc/iso639, and it’s maintained at least in part by the Library of Congress. At least I didn’t know until Sascha Wildner updated it.
Updated: Birthstones and flowers. Don’t know why.
Do you use ndis(4) for a network card that would otherwise not work? Are you running DragonFly 3.3? Are you willing to run USB4BSD and see if it works? If you do, tell Sascha Wildner if his changes worked.
If you are one of the few people still wanting to read an OS/2 HPFS drive, support for it in DragonFly has been updated by Antonio Huete Jimenez. It’s read-only, but writing didn’t work well, and I’d be surprised if there’s any hpfs disks that aren’t archival, out there.
Also, Sepherosa Ziehau has updated the pktgen program to generate even more packets, even at relatively low CPU clock speeds.
The initial download of pkgsrc via Git on DragonFly is a little bit faster now, with the ‘make pkgsrc-create-shallow’ option recently added by John Marino. Note that there’s a similar option for src. It skips downloading file history.
Peter Avalos has updated OpenSSH in DragonFly to 6.1p1. This looks to be a bugfix release, but check the changelog for details.
John Marino’s committed bmake as the replacement to make, as mentioned previously. You should probably do a full buildworld/kernel sequence. This of course only affects you if you are on DragonFly 3.3.
Matthew Dillon’s put more of his Hammer work into DragonFly, with notable parts being the creation of a ‘dmsg’ setup for advertising available block devices to share between machines using Hammer. To anticipate your next question: No, it’s not something you can run right now as a test; this is the underlying framework.
The kernel in DragonFly is now SMP by default. The “SMP” option in the kernel config is no longer needed, so it’s been turned into a no-op. You don’t have to update your custom kernel config… yet.
A conversation about compilers in the DragonFly base system led peeter (must) to describe his group’s use of OpenMPI on DragonFly for physics calculations. Apparently he’s had a significant performance improvement on DragonFly.
Along similar lines, John Marino helped out by bringing in libssp and libgomp for gcc 4.7 for use with OpenMP. (This is in DragonFly 3.3, not 3.2).
Remember the new scheduler work? Well, it continued, and now Francois Tigeot has posted pgbench benchmarks of the progress and benchmarks of DragonFly vs. other operating systems. The links are to PDFs; scroll down as each have multiple pages.
The summary result: If you’re running Postgres, you probably want to do it on DragonFly. The numbers are the best results for any BSD, even better to some extent than Linux, which has had its own issues with schedulers and Postgres. DragonFly 3.2 will include these improvements.
John Marino has accomplished the difficult task of putting gcc 4.7 into DragonFly. Version 4.4 is still the default, and the older 4.1 version has been disabled. If you want to try this newer version, setting WORLD_CCVER=gcc47 will build kernel and world that way too. If you’re curious about what’s different in this version of gcc, there’s a 4.7 changelog.
Are we the only BSD with this new a version in base? I think so.
P.S.: You’ll want to do a full buildworld if you’re running DragonFly 3.1
P.P.S.: you may need to put ‘NO_GCC47=true’ in make.conf, going from IRC comments.
P.P.P.S.: Nope, now it’s fine.