Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release remains 2.4.0-test9. The first 2.4.0-test10 prepatch came out on October 9; it contains a number of USB updates, some miscellaneous fixes, and more virtual memory patches from Rik van Riel.
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:
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.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
October 12, 2000