See also: last week's Kernel page.

Kernel development

Ted Ts'o posted a new 2.4 jobs list on October 9. It remains a lengthy document...

The current stable kernel release is still 2.2.17. No 2.2.18 prepatches were released this week.

Where is 2.0.39? The final prepatch came out a few weeks ago, but the real 2.0.39 release has not happened. It turns out that a few problems have been reported in that "final" prepatch, and they are proving difficult to resolve quickly. David Weinehall has said that the release will happen before too long, even if the problems can not be fixed.

Kernel.org has a new cryptographic key. H. Peter Anvin announced that a new key is now in use to sign files on the kernel.org site. The old one, as it turns out, was set to expire. If you are using the key to verify files downloaded from a kernel.org mirror, you'll need to read the announcement and get a copy of the new one.

Handling 'out of memory' (OOM) situations is a recurring linux-kernel topic. It came up again this week after Rik van Riel posted a patch with a new "OOM killer" routine; this patch subsequently made its way into 2.4.0-test10-pre1.

The Linux kernel, remember, is capable of allocating more virtual memory to processes than it is really able to provide. This is done because processes generally do not use anywhere near all the memory they ask for. To require that the kernel be able to satisfy every last allocation would greatly reduce the total available memory, and would be wasteful. So Linux overcommits it memory.

The consequence of that approach, however, is that the kernel can possibly find itself in a position where it is unable to provide memory to a process that thinks it already has it. It seems to be generally accepted that the only way out of that bind is to start killing processes to recover their memory. Killing processes is not a very satisfactory solution, but it is better than having the whole system lock up.

The hard part, though, is choosing which process to kill. Early OOM killer attempts tried approaches like killing the largest processes on the system. Doing that does indeed recover memory, but usually at the cost of killing the X server or netscape - leading to disgruntled users. So Rik's patch tries to be smarter in how it targets processes. In particular, it:

• tries to avoid processes which have consumed a lot of CPU time, with the idea that killing them would lose a lot of work.

• is more likely to kill processses which have been niced (i.e. are running with lower priority) on the theory that they are less important to the user.

• tries to avoid processes running with superuser privileges or direct hardware access (i.e. the X server).

The targeting of niced processes drew some complaints. Often a process that has been niced is the big cranker job that is the reason for the system's existence in the first place. Rik responded that long-running jobs are unlikely to be killed anyway, and thus the cranker should be safe; in the end, though, he removed the nice penalty anyway.

There was some interesting talk of other approaches. One would be to account for memory on a per-user basis and to kill processes belonging to the user who is causing the problem. That, though, leads to difficulties like figuring out a way for the X server (which often runs as root) to account for resources allocated on behalf of users. Another possibility would be to provide a system call where processes could tell the kernel what their relative importance is. Yet another would be a way for the kernel to signal processes and ask them to voluntarily reduce their memory usage. After all, many processes have memory they could give up if need be; netscape's in-core cache and the X font cache come to mind. However, due to fragmentation issues, memory freed by processes is not necessarily reusable by the system.

In the end, though, the "out of memory" situation is rare, and it is not necessarily worth trying too hard to find a perfect solution. As Linus put it, that perfect solution is probably unreachable, and the attempt is likely to produce worse results than the simple, "good enough" solution. So the OOM killer is probably about as refined as it is going to get.

Updates on the TUX2 patent issue. Last week we covered the three patents held by Network Appliance which appear to cover the "phase tree" algorithm used by Daniel Phillips' TUX2 filesystem. Here's the latest on that situation.

• Network Appliance still isn't responding to Daniel's inquiries on the matter. They seem to be hoping he will just go away. Daniel, however, is not the type to just go away. His position on software patents is very strong, and he means to make a point here.

• As part of making that point, he is looking into filing for some "white hat patents" for aspects of TUX2. The technologies in those patents would only be licensed to free software implementations. His purpose is to make corporations realize that software patents hurt them as well.

• Jeff Merkey of the Timpanogas Research Group has hired a patent attorney to work at busting the Network Appliance patents.

Other patches and updates released this week include:

• Vojtech Pavlik has released a new set of VIA and AMD IDE drivers.

• A low latency patch for 2.4.0-test9 was released by Andrew Morton.

• Modutils 2.3.18 was released by Keith Owens.

• Kesmarki Attila posted a new 3dfx frame buffer driver with a number of nice features.

• Marc Mutz has announced version 0.2.2 of his Encryption HOWTO.

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