Mark Wong posted a series of benchmark results from Rusty Russell's Hackbench. Rusty describes Hackbench as a minimized 'chat benchmark' that doesn't use threads or semaphores. The benchmark launches groups of processes that each listen on a given socket, and complimentary groups of processes that write 100 messages to each of the listening sockets, measuring the time this takes. This process is repeated multiple times with an increasing number of groups of processes, therby measuring the scalability of the scheduler with an increasing number of processes.
Mark's results begin with the 2.5.28 development kernel and continue up through the current 2.6.0-test5 kernel. In a second email he also offers results of the -mm tree, beginning with 2.5.66-mm1 and continuing up through 2.6.0-test5-mm2. Andrew Morton [interview] glanced at the results and commented that they looked "great, but tragically incomprehensible", going on to ask for an explanation, "do we rock or do we suck?". Mark replied, "the general trend in the metric indicates everything has been improving, so I think we rock."
Linux creator Linus Torvalds has released the linux 2.6.0-test5 kernel, with the following comments:
"Lots of small stuff, as usual. I think the biggest "core" change is the Futex changes by Jamie and Hugh, and the dev_t preparations by Al Viro. But there are ARM and ppc updates here too, and a few drivers have bigger fixes (tg3 driver and the USB gadget interface stand out on diffstat). Watchdog driver updates etc. And Russell King fixed more PCMCIA issues."
Read on for the full changelog.
Additionally, if you followed my recent upgrade howto [story], are running a 2.6.0-test kernel, and are interested in upgrading to 2.6.0-test5, read on for a few simple tips on upgrading with incremental patches.
Following Andrew Morton's [interview] recent posting of 2.6.0-test4-mm2 [forum], Christian Axelsson asked, "Is there any work [being] done on getting reiser4 into mm? I havent tried it myself yet but I've heard of colliding code in [the] scheduler". Andrew replied that a merging effort hasn't been made, but that he'd be interested in making it happen in a month or two so long as the namesys developers were willing to commit to providing him with up-to-date patches. Hans Reiser offered:
"We would be happy to make that commitment, and happy to switch from creating snapshots every week to pushing to you and linking to you from our website. Several people have asked for this besides Christian."
In other words, it looks like -mm users will soon have easy access to the resier4 filesystem.
Grant Miner posted some interesting benchmark results to the lkml, comparing five journaling filesystems available with the current 2.6.0-test2 development kernel. The tests were conducted with a very simple shell script, mainly timing how long it takes to copy, tar, and remove directories, performing several syncs in between. He summarizes:
- ext3's syncs tended to take the longest [at] 10 seconds, except
- JFS took a whopping 38.18s on its final sync
- xfs used more CPU than ext3 but was slower than ext3
- reiser4 had highest throughput and most CPU usage
- jfs had lowest throughput and least CPU usage
Some interesting discussion follows, debating the results and offering further suggestions on making the tests more useful. For example, Andrew Morton [interview] proposed including ext2 in the tests as a baseline, and Hans Reiser noted that reiser4 continues to improve rapidly. Read on for the full test results and much of the following discussion.
