See also: last week's Kernel page.

Kernel development

Fixes continue to pour in. Alan Cox's "ac" patches are up to 2.2.1ac4. This patch contains a number of fixes presumably destined for 2.2.2 or so, and the "large file array" patch which apparently is not. There is also a 2.2.2 prepatch put into the "testing" directory by Linus. A 2.2.2 release is this likely sometime in the near future.

Why do I see double network routes with 2.2.x? One change that occurred in the 2.1 series is that the kernel now automatically adds a network route to an interface when it is configured. Thus a separate "route" command is not necessary. Most systems have startup scripts which, not being 2.2-ready, do the "route" command anyway, thus adding a redundant route to the tables. It is harmless, but aesthetically displeasing.

This behavior does annoy a certain number of people who believe that configuring an interface and setting up a network route are two separate tasks. The reply to that objection is that a network interface and its routes are meaningless in isolation from each other, and that a request to configure an interface is also thus by necessity a request to configure the routes that go with it. As with a number of linux-kernel debates, the end result is moot; the current behavior is unlikely to change.

Tar is tremendously slow with 2.2.x is another common complaint. The "slow tar" problem is the result of an interaction between some networking changes and suboptimal system configuration. What's happening is that tar is trying to look up a user ID for each file; the system, which is likely configured by default to attempt NIS queries, is trying to get the answer via NIS. Likely as not the victim is not really running NIS, so no answer is forthcoming. But not getting that answer takes a while.

The solution, for networks where NIS is not used, is to remove all references to NIS and NIS+ in /etc/nsswitch.conf. This problem should also go away once glibc 2.1 comes out, since it implements a caching mechanism for lookups.

What color are your pages? Page coloring has been an occasional topic of conversation for some time, but the amount of interest grew substantially this week.

A superficial understanding of memory architectures helps in the page coloring discussion. Modern memory is slow, much slower than the processor; the result is that your fancy new 1GHz processor gets to spend a lot of time waiting every time it goes to main memory. It's sort of like having a Ferrari in the city. In an attempt to mitigate this problem, one or more layers of fast cache memory are typically placed between the processor and main memory. When a memory page exists in the cache, it can be accessed much more quickly.

A modern PC has some amount of "level 2" cache - typically 128K to 512K worth. There is usually a very straightforward mapping between the L2 cache and main memory, such that for any given "line" (typically rather smaller than a page) in main memory, there is exactly one spot where it can be in the L2 cache. Obviously, this L2 cache line is shared among quite a few main memory lines.

An obvious result of this architecture is that the speed at which any given process can execute is highly dependent on how its pages are laid out in memory. In the worst case, the entire address space of the process can map into a very small number of cache lines. In this case, cache hits are rare and the process executes slowly. If, instead, the process's memory maps across the entire cache, the process will execute much more quickly. Since physical memory layout is a runtime function, compute-bound processes can show a highly variable runtime from one run to the next, depending on its luck in getting well-laid out pages.

Page coloring, in the end, is really just an attempt to control how physical memory pages are allocated to processes in order to produce deterministic cache behavior. The resulting cache behavior is not necessarily optimal, and will likely result in slowing down some processes some of the time. But performance will at least be constant, allowing the programmer to tune the memory behavior of an individual program when the effort is justified. Performance tuning with nondeterministic cache behavior is nearly impossible.

In this context, a few efforts are underway to add page coloring to the Linux kernel, or at least to design it (presumably as a 2.3 project). Richard Gooch has put out a patch (available from his kernel patches page) which provides access to the "model specific registers" (MSRs) in the processor. This access allows the number of cache hits and misses to be measured, which in turn allows developers to measure the effectiveness of any given coloring scheme. Richard's patch also includes a simple page coloring capability, useful for experimenting. Larry McVoy, instead, posted an algorithm for doing effective coloring based on his experience with other OS's. David Miller responded with an approach of his own which also attempts to color pages used for mapped files - an approach which can lead to a globally-colored shared C library, for example.

Those interested in further information on page coloring may want to look at this PhD thesis (postscript format, 1.3MB) on the subject. (Thesis URL posted by Sebastien Gignoux).

Two new kernel mailing lists have been created by Rik van Riel. "Linux-future" was created to discuss and debate possible future developments in the Linux kernel; it has been home to a lively discussion since its creation. "Kernel-doc" is for discussion of kernel documentation, and, hopefully, the production of more of it. Subscription information and archives for both lists (and some others) can be found on the nl.linux.org lists page. There is also a summary of the items discussed in linux-future on this site.

The real-time Linux system has been updated to the 2.2 kernel. This is a development version of RTLinux; it is available from the RTLinux web site.

A new RAID patch is available which brings the new RAID stuff up to the 2.2.0 kernel level. See the announcement for details.

Since we're a weekly publication, chances are we'll be behind a rev or two on the kernel release by the time you read this page. Up-to-the-second information can always be found at LinuxHQ.

Next: Distributions