![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/kernel.png)
|
|
|
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Back page All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel release is still 2.4.0-test11. Some users are complaining about disk corruption problems with this release, so beware. With luck, that problem is fixed in the 2.4.0-test12-pre3 prepatch, which is the latest from Linus. The new arrival in Linus's house is having the expected effect; he has had a low profile on the mailing lists, and the rate of releases has slowed somewhat. Alan Cox has been trying to take up some of the slack by putting out "ac" releases. The latest as of this writing, however, is 2.4.0-test11-ac4, which was released on November 25. The current stable kernel release is 2.2.17. The current 2.2.18 prepatch is 2.2.18pre24. It appears that the remaining issues with this release are mostly solved, so a real 2.2.18 could perhaps come out before too long. The great zero-initialization battle. It may well be that the code freeze is going on for too long. One of the big fights this week isn't over something interesting like reiserfs or capability models; instead, people are arguing over lines of code like:
static int some_variable = 0;
There have been a few patches recently (like this
one which have removed the = 0 part. The reasoning is
that such variables are initialized to zero anyway, so the explicit
initializer is redundant. Explicit initializers are also stored in the
resulting executable, resulting in a larger kernel image. Without the
initializer, the code is equally correct and smaller.
There are a couple of opposing viewpoints, of course. This is linux-kernel, after all. One of those says that it is unsafe to rely on the compiler to perform implicit initialization. That might be true, except that, in the kernel, the compiler has nothing to do with it. The zeroing of the BSS code is done by the kernel startup code itself, and is fully under the control of the kernel programmers. A more interesting viewpoint comes from those who see an explicit initializer as information for the programmer as well as for the compiler. Initializing a variable to zero is a sort of comment that says that the variable's starting value is important, that some code somewhere depends on that initial value. If you see things this way, the removal of initializers makes the code harder to understand and, perhaps, more easily broken. See, for example, this note from Andries Brouwer on the role of initializers in his code. The ultimate decision on such patches, of course, rests with Linus. He has not expressed a general opinion on removal of initializers, but has accepted such patches in the past. Dynamic Probes and the Linux Trace Toolkit play together. IBM's Richard Moore announced this week that the Dynamic Probes patch would now work with the Linux Trace Toolkit by Karim Yaghmour. It has the look of a powerful combination. Dynamic Probes provides the ability to attach a software hook anywhere in a running system - be it in user space or in the kernel. The Linux Trace Toolkit, instead, is a facility for tracing and logging of system events. The combination of the two makes the tracing and logging universal, and monitoring any part of the system becomes easy. See Karim Yaghmour's followup note for one example of how the trace functionality can be used.
Low Latency in the Linux Kernel (O'Reilly Network). The O'Reilly Network is running an article by Dave Phillips on reducing latency on Linux systems. "I have some good news for users and programmers alike: A simple user-applied patch to the Linux kernel sources (and an uncomplicated disk tune-up) can reduce latency times to under 4 msec. Programmers can easily exploit this new low-latency condition by setting scheduler priority from within their applications, achieving performance with latency well within professionally acceptable limits. This article will show you what's involved and how you can do it yourself." On elevators and I/O schedulers. Last week's discussion on the Linux elevator algorithm could benefit from a couple of additions. The first is the simple observation that the term "elevator" should, perhaps, be replaced with "I/O scheduler." As pointed out last week, the Linux algorithm is not a true elevator, and using that term can confuse the discussion. Jens Axboe has a patch to the I/O scheduler (called blk-11 for the 2.4.0-test11 kernel) which addresses some of the problems that people have seen. It starts by adjusting the sequence numbers, as discussed last week. But it goes further by also taking into account the size of I/O requests (an operation that has to wait behind a very large request will get more credit) and applying a simple aging algorithm as well. The result should be fairer scheduling, with fewer starvation problems. (Of course, most users don't see such problems now). The patch also addresses some other problems in the block I/O queueing mechanism which can cause poor performance in very busy situations. LWN reran its highly scientific tests from last week using the blk-11 patch; here's an updated table with the new results:
The second number in the "compare" case is with the latency values set to zero (the rest used the defaults). Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
November 30, 2000
| ||||||||||||||||||||||||||||||||
Copyright © 2000
Eklektix, Inc., all rights reserved
Next: Distributions