On the Desktop
Linux in the news
All in one big page
See also: last week's Kernel page.
The current kernel release is 2.4.7. See the changelog for the list of fixes in this release. As of this writing, there are no 2.4.8 prepatches, 2.4.7 "ac" patches, or signs of 2.5.0 out there.
Linux Device Drivers, Second Edition, available online. The full text of the second edition of Linux Device Drivers by Alessandro Rubini and LWN editor Jonathan Corbet is now available online on the O'Reilly web site. The book is freely redistributable under the terms of the GNU Free Documentation License.
Finding single-use pages. Daniel Phillips has, for the moment, turned his attention away from directory indexes, and is working on ways to improve Linux's virtual memory performance. To that end, he has attacked the problem of single-use pages - pages in memory that will only be used once. Such pages are often, but not always, associated with file I/O. Single-use pages, clearly, should be the leading candidates to be thrown out when memory is tight; after all, they will not be used again.
The hard part, of course, is figuring out which pages are of the single-use variety. Daniel's approach involves, essentially, initializing a new file I/O page in the "inactive" state. Only on the second access will new pages go into the regular management scheme. With luck, single-use pages will never become truly active, and will get flushed out quickly.
As usual for Daniel's patches, there is an attached description which discusses what's going on far more clearly than we could do it; a reading is recommended for anybody who is interested in how VM works now, and how the change works. Linus really likes the patch, and is looking to integrate it quickly if it holds up in wider testing.
What's that new process in 2.4.7? Sharp-eyed users of 2.4.7 may have noticed one or more new entries in their ps listings that look like:
3 ? SWN 0:00 [ksoftirqd_CPU0] 4 ? SWN 0:00 [ksoftirqd_CPU1]These processes are the only user-visible signs of a fairly significant change in the way the kernel performs event handling.
The Linux kernel, like many others, incorporates a "soft interrupt" (or "softirq") mechanism. A softirq is similar to a hardware interrupt, in that it can be delivered asynchronously and is intended to handle events which may not be related to whatever process is running at the time. A softirq, however, is set up by the software itself, and it is delivered at a time that is relatively convenient for the kernel code.
Softirqs exist to enable asynchronous processing that is too large to be handled during a hardware interrupt. An obvious example is the networking code. A hardware interrupt is generated when a packet arrives, but it would be highly inappropriate to perform all of the protocol handling at that time. Instead, the (hardware) interrupt handler performs the minimum possible work; things like acknowledging the interrupt, and, maybe, handing the packet over to the networking subsystem. Then a softirq is requested to actually do something with the packet. Many other device drivers (and other kernel subsystems) use softirqs for deferred processing, often in the form of tasklets and "bottom half" processors.
About a month ago, Andrea Arcangeli pointed out some problems with how softirqs are handled. Up through 2.4.6, there were two places where a softirq would generally be run: (1) immediately after the handling of a hardware interrupt, or (2) in the scheduler. Due to the way things were done, there could be a significant passage of time before a softirq would actually run. More seriously, softirqs could be invoked within softirqs, leading to stack overflows. It was also possible, in some situations, for softirqs to saturate a CPU, starving the rest of the system. For example, a high-bandwidth network stream could bury the system in networking softirqs, making the system unusable.
Andrea's fix was to create a separate kernel thread for the processing of softirqs. In this way, the softirqs are guaranteed to be serialized on each processor (since the thread handles one at a time), and they are unable to take over, since the 'ksoftirqd' process is scheduled like any other (albeit at a high priority). The patch, after some tweaks, seems to handle the problems well and was incorporated into 2.4.7pre5.
Not everybody is happy with the fix - some think that compute-intensive processing, such as network protocol handling, should be moved into its own thread rather than moving the entire softirq mechanism. But those arguments are moot, since the patch has been incorporated. Instead, the real debate now seems to be over how the process should be named: it seems that some people find ksoftirqd_CPU0 to be excessively ugly. Names like kirq0 are being proposed instead. This issue, however, does not look like the kind that reaches a simple, quick resolution...
Filesystem performance compared. Denis Lackovic and colleagues have posted a set of performance comparisons for six different filesystems. The results are surprising at times, and distressingly inclusive. You'll not know which filesystem to use after reading the results, though you'll have learned quite a bit. They were able to determine, however, that people who are concerned about performance should not be using VFAT.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
July 26, 2001