Sections: Main page Linux in the news Security Kernel Distributions Development Commerce Announcements Back page All in one big page See also: last week's Kernel page. |
Kernel developmentKernel version 2.2.4 has been released. Last week, we optimistically theorized that the 2.2.X kernel series was stabilizing rapidly. The 2.2.4 release, announced by Linus, somewhat dampened that optimism. Compilation problems were quickly found in the new kernel, in the BSD process accounting code. A patch was quickly made available for that, but another problem was found for people who enable Kernel/User netlink socket, Routing messages, and Netlink device emulation, but don't enable Ingres traffic policing. Patches for both of these problems can be found on Robert Gooch's new page, which will be used to track known problems with patches available for the latest kernel. In addition to the compilation problem, there have been a large number of reported oopses for this most recent kernel. These include two reports of "put__dirty_page: page already exists" errors in syslog during compilations (reproducible in 2.2.3 as well), and a potential problem under certain load conditions. Linus generated a one-line testpatch for the latter, which he has asked people to check out to see if it makes any difference. Apparently the circumstances that might generate the load problem would be fairly pathological, and therefore highly unlikely to occur, at least in theory. Last, there are some oopses occurring that may be caused by a bug in egcs, or at least triggered by a difference in behavior between egcs and gcc-2.7.2 (or possibly not). As demonstrated in this note from Linus, tests on this problem are at too early a stage to be able to actually point a finger. In the Alan Cox tree, 2.2.3ac3 and 2.2.3ac4 were both announced this week. Presumably 2.2.4ac1 will be out shortly. Meanwhile, the longest running discussion of the week focused on file system performance. Starting with this note from Yasushi Saito about disk head scheduling, the thread broke into several lengthy discussions. The first thread focused on whether or not optimizing for disk architecture was worth doing. The answer, in the end, is no, because modern devices do not accurately provide the physical layout of the disk. As Linus stated, " Quite frankly, anybody who even _thinks_ he knows how the disk is organized is living in the past. Give up on it, and just consider it a linear array of sectors. In addition, any potential performance improvement would be offset by the disadvantages of the added complexity of the code. This discussion, however, spawned a new one on the kernel IO-request queue. Many people assume that the kernel IO-request queue is a single queue. Linus retorted emphatically that it is not, blaming the misapprehension on the way the SCSI layer is designed. The conversation then moved to discussing how the SCSI layer should be improved. Work on it has been dropped for quite a long time. It seems like that may change soon. Here is a nice final summary from Gerard Roudier. Lest you think, though, that a unanimous opinion on the problem was reached, this note from Gadi Oxman describes how the current behavior evolved and the advantages of it. Last, it was suggested that the issues are all moot, since disk drives using static RAM may become actually affordable in a few years. "Disk drives currently under test use static RAM. This is not the Slow........ NVRAM where you write then read-read- read-read, etc., until it finally "takes". This is real static RAM with a 3-volt battery to keep it alive for 20 years," mentioned Richard B. Johnson. Nicholas J. Leon commented that he has built specifications for a RAID system using such technology. 60GB of data for over $50,000 using solid state disks and a fibrechannel backplane ... not affordable quite yet! For followup information on the above topics, check out this list of publications. Modutils 2.2.2 is nearing release. Bjorn Ekwall expressed his optimism when he released modutils-2.2.2-pre3 and it is still likely, even though he released modutils-2.2.2-pre4 shortly after pre3. Note that pre4 also requires a small patch. Discussion of a buffer hash leakage in Chuck Lever's instrumentation patch generated three patches, one from Andrea Arcangeli, one from Chuck Lever himself, and a last patch from Linus. Linus' patch was checked out by Stephen Tweedie and given the thumbs up, at least for now. CPU Management for Linux was the topic of this posting from Martin Neumann. In this case, cpu management means the ability to handle hot-pluggable CPUs. Martin asked if this was in the works for Linux. Jakub Jelinek and Alan Cox confirmed that it is on the to-do list for the 2.3 series, along with hot-pluggable memory. From the discussion that resulted, no one expected this to be that difficult to add in. Various other patches and utilities released over the last week:
Section Editor: Jon Corbet Guest Editor for the Week: Liz Coolbaugh |
March 25, 1999
| |