Kernel development [LWN.net]

Release status

Kernel release status

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 fixes.

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 problems.

Comments (2 posted)

Kernel development news

Swsusp approaches readiness

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 laptop.

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)

The scheduler saga continues

At the conclusion of last week's episode, 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 scheduling.

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 "interactive."

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)

IA-64 milestone

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)

Changing RCU in 2.6.3?

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 to say:

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

Kernel trees