Sascha Wildner has moved gcc in DragonFly to a slightly newer version: 4.4.5. It mostly seems to make things easier to compile, going by the reports I’ve heard. This is the version that will be in DragonFly 2.10.
Category: Committed Code
Enabling the vfs.hammer.double_buffer=1 sysctl will greatly improve Hammer performance when you’ve exceeded your memory cache (at a possible slight penalty when you have not) and also speed things up when using live deduplication.
Update: Venkatesh Srinivas says:
“double_buffer makes sense when: 1) you want all CRCs to be checked on reads. 2) you’re running live dedup and care about dedup performance rather than say read-heavy performance; 3) you have swapcache but are often running into the vnode limit in what you can cache.”
So, not always useful.
Also, Matthew Dillon has made version 6 the default version of Hammer in DragonFly 2.9. Version 6 has improved handling of directory names in some circumstances. Just don’t ask me which, cause I lost track. It’s been a hard day!
If you’re using pf to control how your bandwidth is used, you may want to look at the recent fairq updates from Matthew Dillon. It should perform better now in situations where one traffic group is saturating its available bandwidth. Here’s a handy link that explains this sort of problem, yoinked from IRC.
John Marino’s work on getting support for DragonFly ‘natively’ into binutils, upstream, has been successful. Thanks, John!
There’s two recent changes for pkgsrc and DragonFly:
- DragonFly-current (2.9) now pulls the most recent pkgsrc quarterly release (2010Q4) by default, instead of pkgsrc-current. This means more packages will be working with the default setup, plus pkg_radd and other tools will be pulling the same ‘generation’ of software.
- The DragonFly/git version of pkgsrc can now be created as a shallow clone. This means less file history, but also means a much faster download.
A full buildworld/buildkernel is probably the best strategy. I’ll be rebuilding all the pkgsrc packages for 2.9 using gcc 4.4… This will take at least a week.
Matthew Dillon’s improved bridging to the point where you can now modify the MAC address of the bridge and most everything, including ARP, will come from it correctly. It’s even possible to bond 2 or more interfaces together, with the side effect of dragonflybsd.org having a lot more bandwidth.
Update 2: More notes here.
Matthew Dillon has continued his bridge work, with another commit adding various features. Go, read.
Matthew Dillon has added transparent bridging, mostly to overcome issues with the AT&T DSL modem he’s using. With this non-default feature, IP packets retain the original MAC address when retransmitted through a new interface.
As Matthew Dillon notes in a recent post, procedures are now assumed to be MPSAFE (i.e. without the Giant Lock) by default. Any new work should follow this idea, and it doesn’t have to be documented specially. The inverse used to be true, where the code that happened to work without the Lock was rare, and therefore needed to be pointed out. Now, the good result is the norm.
Matthew Dillon’s made some scheduler changes, which blogbench tests are showing give the default scheduler better performance under heavy load. It’s a pretty technical writeup, so I’ll just point you at it rather than attempt to summarize.
Matthew Dillon’s made some changes that will speed up the booting process for people with a ridiculous amount of memory, like 64G. This is x86_64 only, but that should not be a surprise if you think about it.
Global tokens are now running without the giant lock in DragonFly. Neat! There’s still plenty more to remove, but this is a big step.
The default Hammer version in DragonFly is now version 5, which is the one that includes deduplication. Enjoy, bleeding-edge users! Otherwise, wait for the next release.
Version 6 is there, but don’t upgrade to it yet; there aren’t significant user-visible changes, and the usual disclaimers for new versions apply.
Ilya Dryomov has added live deduplication, or as he titles it, “efficient cp”. It’s experimental and turned on with a sysctl, so approach with caution.
Xerox Network Services is gone from DragonFly. Does anyone, anywhere, use this protocol? Ironically, I don’t recall this even being visible on the Xerox hardware products I have at work.
Another bus bites the dust: EISA is no more on DragonFly. I don’t know if there’s even any system that DragonFly could boot on and would use this. Still, remove your hats and enjoy a moment of silence.
Matthew Dillon fixed a rare and difficult-to-find bug on x86-64 Dragonfly. This means much more of the system can be run ‘MPSAFE’, or without the Giant Lock. Watch for this soon if you’re running 2.9.
Ed Smith was thinking of working on sysctl documentation, but as it turns out, a lot of it has already been done via Google Code-In; Samuel Greear recently committed a lot of it. (Though there’s more sysctl work possible.)
While on that topic, Samuel Greear also posted a lengthy summary of all the Code-In work done so far. We need more code-related tasks! The existing ones have been so popular that they’re all getting done, quickly.
Matthew Dillon has moved CPU support to 63 processors and 512G of RAM. This may cause issues, he warns. It’s also just barely working, so don’t expect to go into production with half a terabyte of RAM in the next few days.
There’s now descriptions for a number of the net.inet.* sysctls, thanks to Taras Klaskovsky as part of Google Code-In.
APIC_IO is back as a kernel config option, though it just toggles the sysctl loader tunable default. This is so a kernel config file with that option still set won’t cause an error.
Ilya Dryomov’s work on deduplication for Hammer has been committed to the tree in an early test form. I guess I need to pay up as part of the code bounty. If you’re wondering how much space it will save, but don’t want to try non-production code yet, there’s a ‘hammer dedup-simulate’ command that will estimate the saving ratio.
This is great news – deduplication is so valuable it adds an extra zero onto the price of any storage device that can do it.
DragonFly has shipped with a uniprocessor kernel by default forever. Shipping with a SMP kernel may not work as well for all possible combinations. With some recent changes by Matthew Dillon, both types of kernel are present and can be picked from at boot time – with the LiveCD!
Venkatesh Srinivas has a large writeup describing just how the memory allocator in DragonFly changed from 2.6 to the upcoming 2.8 version. In all that text, you may notice the cheering statistic that it gave a 20% improvement in sysbench results.
Matt Dillon and Venkatesh Srinivas conspired to fix another nmalloc issue, which should resolve any remaining problems people were having with Firefox, and possibly other applications as well. Due to an oversight of sorts, all locking operations on nmalloc’s depot were ineffective, as if there were no locking at all. Curiously, it worked remarkably well considering such a large race condition was present.
I’m linking to this commit message from Matthias Schmidt simply because it has the correct invocation for installing a vkernel, and I know this will come in handy, someday.
A bump in shared library version for libssl/libcrypto means that any programs dependent on it will require a rebuild – including any pkgsrc programs.
This only affects you if you are running 2.7, for now. It means that on upgrading from 2.6 to 2.8, any libssl-using programs will need to be updated. This may not be a big thing, since pkgsrc-2010Q3 will also be out and people will want to upgrade anyway.
Did you know Fred is the name for the DragonFly mascot? Well, you do now. He’s also back in the bootloader, thanks to Joe Talbott.
DragonFly’s version of pf (corresponding with OpenBSD’s 4.2 version) is now multiprocessor safe, to match the network stack. pf itself isn’t using multiple processors; it’s just able to work without causing problems in an otherwise MPSAFE environment, thanks again to Jan Lentfer. Note that there’s one minor caveat.
Swapoff has been added to DragonFly. This was a potential Summer of Code project, and also happened to have a bounty offered for it. $300 goes to Ilya Dryomov. If money for code like this interests you, check the Code Bounties page for more projects…
Dear universe: improved interrupt routing, or deduplication in HAMMER would make me happy. I’m not picky.
A little work has snowballed into even more of the network systems in DragonFly being pulled apart in order to get rid of the Giant Lock. It may delay the 2.8 release by a week or two, but it’s already paying dividends, such as NFSv3 now performing at maximum physically possible speeds on gigabit Ethernet.
(I ran out of alliterative words, sorry.) Venkatesh Srinivas has committed his work on memory allocation; his commit message has details. He’s kindly provided a link to the article that inspired the per-thread magazine work. He’s also provided graphs to show comparative performance benefits of his new memory allocator on DragonFly and on FreeBSD.
A familiar procedure in any open source project: irritation causes improvement. In this case, the Forth-based boot loader irritated Matthew Dillon into writing a new replacement C-based one. (See the commit too, and it may slightly affect the upgrade process for 2.7 users.)
Full buildworlds again, as there’s more commits that make it necessary. If you’re running 2.7, you should probably just plan on using buildworld, and not quickworld for rebuilding.
System data structures have changed again, so make sure your next rebuild is a full buildworld/buildkernel if you’re running 2.7. There’s been a lot of changes to pull more and more out from under the Giant Lock.
Matthew Dillon posted a summary of recent bugfixes in HAMMER and kqueue, which means if you are running a version of bleeding edge DragonFly build in the last few weeks, you should update.
He also mentions a “significant improvement in performance” in disk encryption. How significant? Over three times as fast.
Matthew Dillon reports that DragonFly now has a catastrophic recovery tool for HAMMER filesystems, with pertinent details.
Matthew Dillon has provided some details about recent kernel work, along with a release forecast.
Update: As Venkatesh Srinivas pointed out in the comments, adding DSCHED_FQ to GENERIC does not make it the default, but you no longer have to load the fairq module. Which raises the question, should fairq be the default?