Slashdot Mirror
Linux 2.6.38 Released
darthcamaro writes "The new Linux 2.6.38 kernel is now out, and it's got a long list of performance improvements that should make Linux a whole lot faster. The kernel includes support for Transparent Huge Pages, Transmit Packet Steering (XPS), automatic process grouping, and a new RCU (Read/Copy/Update)-based path name lookup. '"This patch series was both controversial and experimental when it went in, but we're very hopeful of seeing speedups," James Bottomley, distinguished engineer at Novell said. "Just to set expectations correctly, the dcache/path lookup improvements really only impact workloads with large metadata modifications, so the big iron workloads (like databases) will likely see no change. However, stuff that critically involves metadata, like running a mail server (the postmark benchmark) should improve quite a bit."'"
he could argue that making the kernel faster makes the OS faster
which is what the quote said
It is great news that the Linux kernel performance keeps improving, and nowadays you can get the fastest performing commonly used OS for free. But I have to point out that the way the slashdot summary was written is misleading. The slashdot summary has the following quote:
'"This patch series was both controversial and experimental when it went in, but we're very hopeful of seeing speedups," James Bottomley, distinguished engineer at Novell said. "Just to set expectations correctly, the dcache/path lookup improvements really only impact workloads with large metadata modifications, so the big iron workloads (like databases) will likely see no change. However, stuff that critically involves metadata, like running a mail server (the postmark benchmark) should improve quite a bit."'
If you read the actual article you will notice that this quote refers only to the RCU portion. Other aspects like transparent huge pages are not controversial and they will improve database performance.
In my opinion, Android isn't the first Linux-based project to rely on a custom kernel. I've seen many such systems pop up in the industry, most of them dead and gone now. The reason is that once the fork has been created, it falls out of development and becomes obsolete after a time. The Linux kernel has been customized and forked by projects countless times. What's going to happen is that the fork is simply going to become outdated and once it's obsolete, the current Linux kernel will have to be forked yet again. Re-forking becomes inevitable part of the project's continued development.