The current development kernel is 2.6.0-test2
; Linus has not
released any development kernels over the last week.
Linus has been busy, however; his BitKeeper tree contains a substantial
pile of patches, including a merge of the SELinux security module, a new
print_dev_t() function which is portable across architectures (and
dev_t size changes), some power management and software suspend
fixups, an ALSA update, some disk readahead changes (avoiding work if the
drive is too busy to do readahead anyway), and, of course, a vast number of
The current stable kernel is 2.4.21, but 2.4.22 is getting closer:
Marcelo announced the first release
candidate on August 5. The time has come for those with a serious
interest in 2.4.22 to do some real testing and shake out the remaining
Comments (2 posted)
Kernel development news
Your editor recently replaced his venerable Sony 505-FX laptop. That
machine had a nice feature - hitting a certain magic function key sequence
would cause the APM BIOS to take over, save the contents of memory to disk,
and suspend the system. The Linux APM code would let the kernel trap the
events and do things like flush out disk buffers (before suspending) or
reset the system clock (after). It all "just worked."
The new laptop has the same little "suspend" symbol on the same key, but it
doesn't work. In the modern, ACPI world, it is the operating system which
is responsible for suspending and resuming the system. This change is,
somehow, presented as progress. The version of Windows shipped with the
laptop is able to perform this operation, of course. Strangely, Sony does
not support Linux to the same level. Your editor, it seems, was doomed to
head off to the Kernel Summit and
OLS with a non-suspending
Then came the announcement that software
suspend for 2.4, v1.0, was available. LWN has covered the swsusp patch before, but swsusp has
long been in the "almost works" category. For a long time, it appeared
that not much was being done in that area. More recently, the swsusp
effort has picked up steam (as more kernel hackers get new laptops,
perhaps). Thus, the 1.0 release.
The swsusp tarball yielded a series of patches; the user has to decide
which ones to apply depending on what other patches are of interest. For
example, if the target (2.4.21) kernel has the ACPI patches in it (pretty
much mandatory for many laptops), a separate swsusp "option" patch must be
applied as well. The swsusp "Applying" file covers the necessary patches
(and required order) reasonably well - for somebody who is comfortable
messing with highly patched kernels.
The patch also comes with a "hibernate" script which is used to actually
kick off a software suspend operation. This (lengthy) script tries to get
everything into shape for a graceful suspend; in many ways, it behaves like
a partial shutdown. Certain processes are killed off, as many modules as
possible are unloaded, etc. On resume it restores the clock, reconfigures
network interfaces, and, perhaps, engages in some complicated gymnastics in
an effort to get X and the video hardware back in sync.
The bottom line is: it works. On your editor's laptop, an invocation of
hibernate saves state and takes the system to a power-off state in
16 seconds. Returning to a full X display takes a little longer: 34
seconds, after the BIOS finishes its power-on ablutions. To say the
least, this is a nice functionality to have in a laptop, especially when
one is attempting to cover a conference.
The one bit of remaining difficulty is the laptop's Radeon video hardware,
which refuses to come back into any sort of reasonable, useful state.
There is, evidently, a patch for XFree86 which makes this problem go away.
But your editor, who has no trouble with patching a kernel to a pulp, shies
away from patching and installing XFree86. It was far simpler to tell X to
run in the unaccelerated, dumb frame buffer mode, which works just fine.
For those who are interested in 2.4 software suspend, the first swsusp 1.1 release candidate was
announced on August 5. There's a number of useful changes in this
version, but the largest is probably the ability to save system state to
swapfiles (previous versions only worked with swap partitions). Software
suspend support in 2.6 is in more of a state of flux; the power management
changes have still not been merged, and work is being done to make the
swsusp support cleaner, more flexible, and more robust. 2.6 should
eventually have a solid swsusp implementation, though it may still be
stabilizing when 2.6.0 comes out. It is unclear whether swsusp will ever
be merged into the 2.4 kernel; it is a somewhat invasive patch to apply to
a stable series.
Comments (10 posted)
At the conclusion of last week's
, Con Kolivas and Ingo Molnar were busily trying to improve
interactive response in the 2.6-test scheduler through a variety of
techniques. Con had picked up some of Ingo's changes, but had passed over
others. In particular, Con thought that Ingo's nanosecond timekeeping
functionality added extra overhead without really helping with interactive
So it was, perhaps, a surprise to some when Andrew Morton's 2.6.0-test2-mm3 kernel came with a little note:
"Con's CPU scheduler rework has been dropped out and Ingo's changes
have been added." There is a useful lesson here that has been
learned several times on linux-kernel: when Ingo starts to think seriously
about a development issue, it's usually worthwhile to pay attention to what
he comes up with. (Incidentally, Andrew merged Ingo's 4G/4G patch as well).
In particular, it seems that Ingo's nanosecond timekeeping in the scheduler
was necessary after all. The interactivity patches try to give a priority
boost to processes which perform short sleeps, and tracking those sleeps in
jiffies (usually 1/1000 second in 2.6) was insufficiently precise. Con reworked
his patch to use the higher-resolution times; the resulting O12.2int patch found its way back into 2.6.0-test2-mm4. Beyond the timekeeping
change, the patch continues to tweak the various parameters, but mostly
sticks to the techniques for discovering interactive processes that were
discussed last week.
Con's O13int goes a little further, however,
and denies an interactive bonus to processes for non-interruptible sleeps.
This type of sleep (which shows up in ps output as the dreaded
"D" state that can mark a non-killable process) is usually (but
not always) associated with a wait for disk I/O. Con's observation was
that processes which are pounding on the disk are usually not performing
truly interactive work, and shouldn't get the associated bonus.
This approach has a problem, however: the recently merged anticipatory
I/O scheduler will, on completion of a read request, idle the disk briefly
on the expectation that the reading process will immediately issue another,
nearby request. But if the scheduler makes the reading process wait (since
it was in a non-interruptible sleep and doesn't appear to be interactive),
the next read request may not arrive in time, with the result that the I/O
pause was done in vain. Idling a disk for no useful purpose does not help
response, interactive or otherwise. In the end, Con tweaked the code to allow tasks to build up
enough credit in non-interruptible sleeps to just barely qualify as
Since then, scheduler tweaking activity has slowed a bit. For the time
being, it seems, most of the ideas in circulation have been tried out.
Perfection in the scheduler is probably an unattainable goal; it may be
that it will soon be time to declare victory and move on to other issues.
Comments (2 posted)
It may seem like a small victory for some, but
David Mosberger seemed pleased enough when he announced
that, as of August 4, the
official Linus kernel builds correctly on the IA-64 architecture with no
additional patches needed. Non-x86 architectures often require external
patches to build correctly, and Itanium has been no exception. In fact,
IA-64 required a larger set of patches than most; the port was
initially done with a rather un-subtle hand. It has taken a lot of work
from numerous developers to bring the two trees back together;
congratulations are due.
Comments (1 posted)
Dipankar Sarma recently posted a pair of
patches which change the interface to the read-copy-update functionality in the
kernel; these patches shrink the rcu_head
structure and change the
prototype of the call_rcu()
function. Andrew Morton's response
was that the patches looked good, but
now the focus was on stabilization, not improvements. He went on
Oh I'd be okay with merging a change like this into (say)
2.6.3-pre1, without it having had a run in 2.7. We need to be able
to do things like that.
The only problem with this plan, of course, is that such a change would
break all code using RCU - during a stable series. The rcu_head
structure changes would break binary modules; very few developers are
particularly concerned about that. The call_rcu() prototype
change, however, would be a source API change; that sort of thing worries
more people. Some objections were raised, but it appears that Andrew's
plans have not changed. RCU users may want to bear in mind that an API
change may well happen early in the 2.6 series.
Comments (1 posted)
Patches and updates
Core kernel code
Filesystems and block I/O
Benchmarks and bugs
Page editor: Jonathan Corbet
Next page: Distributions>>