Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.4.0-test3. This revision is a 4.5MB patch which touches over 1100 files and brings some significant changes. It contains a great many architecture-specific updates, including the addition of Cobalt Microserver support as a separate MIPS sub-architecture. There is the addition of a massive "ACPI interpreter" (it adds 120KB to a compiled kernel) which will someday make advanced power management capabilities available. The "memory technology device" driver has been integrated, bringing support for a great many "disk on chip" and flash memory devices; along with this support comes the Journaling Flash File System from Axis Communications. Also in this patch is an IEEE1394 ("firewire") update which includes new video support, an experimental USB Bluetooth driver, a Keyspan USB-to-serial driver, a reorganization of the USB storage driver, a major cleanup of the slab memory allocator, a reworking of the IP packet reassembly code, and the usual long list of little fixes.
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:
Section Editor: Jonathan Corbet
July 13, 2000