1 2 next »

Kernel Log: Linux 2.6.35 taking shape

by Thorsten Leemhuis

Linux 2.6.35 will deliver better network throughput, support the Turbo Core functionality offered by the latest AMD processors and de-fragment memory as required. On LKML, a discussion on merging several patches developed by Google for Android is generating large volumes of email.

Two weeks on from the release of Linux 2.6.34, on Sunday night Linus Torvalds released the first pre-release version of Linux 2.6.35 to concluding the merge of the major changes for the next kernel version, expected to be released in about ten weeks. The merge window has once again stretched to around 14 days, after its abbreviation in Linux 2.6.34 caused confusion among some subsystem maintainers.

As usual, the next version of the main development tree will include many changes and enhancements to infrastructure and drivers. Changes introduced by Google developer Tom Herbert mean that the kernel's network subsystem now supports receive side packet steering (rps) and receive flow steering (rfs), both of which improve the way the steps for processing received network packets are distributed across available processors. As a result throughput is increased and latency reduced.

Memory compaction should allow the kernel to reduce memory fragmentation on demand. This allows the creation of larger areas of free memory which can be used with larger page sizes, reducing overhead. Linux 2.6.35 will also include full support for the Turbo Core functionality offered by the latest AMD processors, which allows them to ramp up clock speeds at low loads.

Kernel hackers have also been working on beefing up the rudimentary support for power saving features on Radeon graphics chips offered by Linux 2.6.34. The code for cpuidle now keeps better tabs on system load to ensure it doesn't reduce throughput through over enthusiastic use of the run-time processor sleep mode.

As ever, over the next few weeks Kernel Log will be reporting on these and hundreds of other changes in Linux 2.6.35 on The H. Between 2.6.34 and 2.6.35-rc1 there were a total of 8113 commits in the main development tree which, according to diffstat, added 609,506 lines of code and removed 270,035. Around two thirds of these were concerned with modifications to driver code.

2.6.35 significantly slower?

Phoronix, a website specialising in Linux hardware topics, claims its speed tests show that, over the last few days, the Linux kernel in the main development tree has been running significantly slower than the old kernel. The Phoronix website dedicates a five page article entitled "The Huge Disaster Within The Linux 2.6.35 Kernel" to the subject.

This looks like a lot of effort to go to for a pre-release version of 2.6.35, with nearly two months likely to elapse before the kernel proper sees the light of day – indeed at the time of testing no pre-release version of 2.6.35 had even been released, as the Phoronix team acknowledges in the first paragraph of the article. There is plenty of time to deal with any performance problems.

Nonetheless, reports of performance problems in pre-release versions can be found in great numbers on the Linux Kernel Mailing List (LKML) – they are picked up every couple of weeks, or months, by testers at AMD, IBM, Intel or elsewhere. Even on media platforms specialising in Linux this barely merits a mention, since there are usually good reasons for variations in performance and any genuine problems are fixed by the time the kernel version in question hits the streets.

One can, as for any benchmark, also quarrel over the real-world relevance of the tests – indeed among kernel developers Phoronix does not enjoy the best of reputations in this respect (e.g. 1, 2, 3). The current tests, for example, were carried out on two net-tops with feeble Atom processors. Both registered a major drop in performance, with the biggest drop being seen on the net-top running on a Poulsbo chip-set, a chip-set which is avoided by many Linux users due to problems with drivers. This net-top was also using the Btrfs file system, which is still marked as experimental and is not yet considered suitable for live use.

On Monday night the kernel developers were informed of the problem. There is some speculation as to the root cause, which might have already been fixed. In the scope of that discussion Dave Airlie criticised the work of Phoronix in a broader scope; Ingo Molnar pointed out, that although Phoronix' actions might not be helpful, the kernel developers will have to get used to this sort of thing.

Next: Linux version status, Android and the Linux kernel, In Brief

1 2 next »