See also: last week's Kernel page.

Kernel development

Here's the diffstat listing for those who want to see the full list of files changed by this patch.

There is also a 2.4.0-test4 prepatch out there, currently in its fifth revision. This relatively small patch includes the addition of support for Orion boards as another MIPS sub-architecture, a big update to the Microgate SyncLink ISA and PCI serial adapter driver, more ACPI code work, and a number of other small tweaks.

The current stable kernel release is still 2.2.16. The 2.2.17 prepatch is up to 2.2.17pre11, but there was no announcement for this revision. Alan does say that he hopes 2.2.17pre12 "or so" will be the final prepatch release.

Latency, continued. The latency discussion continued to simmer slowly over the last week, in a more constructive mode. It may well be that a Linus-acceptable, low-latency patch will make it into the 2.4 kernel.

Latency problems come about when the kernel code spends an excessively long time on one task, to the detriment of others. Thus all of the attempts to attack latency problems have come down to finding places where the kernel hogs the CPU for too long and breaking them up. In the end, a low-latency patch consists mostly of the addition of "rescheduling points," places where the code checks for other things to do and possibly allows another process to run.

The addition of rescheduling points must be done with care, since the kernel is full of places where it is not prepared to be interrupted. It is also easy to get into the mode of tossing rescheduling points in everywhere, without really thinking about whether they are really needed or whether there is a better solution to the problem. Linus's objections to the current patches are based in a dislike of the shotgun approach to rescheduling points. A few, well thought-out points are acceptable; lots of them are not.

Thus the current work is aimed at the insertion of a minimal number of these rescheduling points, and justifying each one well. Andrew Morton has taken on this task, and appears to have come up with some good results. He posted an initial patch which inserted six rescheduling points, and which reliably produced 4ms latency results as long as you avoided things on his "don't do that" list (included with the patch). He also made available a set of tools for measuring latencies.

That patch drew a few complaints because one of the "don't do this" items was deleting large files - something that people who work with audio tend to do a lot of. That particular problem turned out to be solvable. The latest version of the patch is up to nine rescheduling points, and provides latencies of less than 1ms 99.999% of the time.

Linus has not passed any (public) judgment on this patch, but it would appear to meet his criteria for an acceptable low-latency fix. It may well go in. Meanwhile, the long-term solution is likely to be different - the 2.5 development series will probably make kernel code preempt-able in most places. At that point, most of the code is automatically a rescheduling point, and the need to put them in explicitly will go away.

(Roger Larsson has also updated his latency profiling patch).

Memory management - the other performance problem. The current development kernels still have significant problems with memory management in some situations, leading to much worse performance than 2.2 in some situations. A number of kernel hackers are currently working on the problem, which is perhaps one of the biggest obstacles to the 2.4.0 release. The problems, unfortunately, are not something that can be fixed with a few small tweaks; it goes deeper than that.

One thing that needs to be done, according to Stephen Tweedie, is to separate the tasks of taking memory away from a process and committing its contents to disk. The addition of this sort of "multiqueue" structure, being done by Rik van Riel, will make a lot of tasks easier; according to Stephen: "I really think we need to forget about tuning the 2.4 VM until we have such fundamental structures in place. Until we have done that hard work, we're fine-tuning a system which is ultimately fragile."

In other words, it is going to be a while before Linux memory management is ready for 2.4.0.

The 2.5 development series looks to be fun as well, since there seems to be a consensus that memory management needs to be thrown out and done over at that point.

The Linux-USB mailing lists are moving. Have a look at this announcement to see how to make the transition and subscribe to the new lists.

Other patches and updates released this week include:

• Stephen Tweedie released version 0.0.2e of the ext3 journaling filesystem. This release was quickly followed by version 0.0.2f, which fixes a problem that came up.

• Speaking of journaling filesystems, ReiserFS 3.6.11 was also released this week.

• Devfs v176 was released by Richard Gooch.

• Keith Owens has released modutils-2.3.12; this release contains a necessary fix for those using the current devfs code.

• Ftape-4.03 was released by Claus-Justus Heine. He has also announced that 4.03 will be his last release, and has requested that somebody else step forward as the ftape maintainer. This could be a good task for somebody looking for a way to help out kernel development.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap 2.5 Status

Other resources: L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions