Official website for Linux User & Developer
FOLLOW US ON:
Feb
25

The kernel column

by Jon Masters

Last month saw the opening (and then closing) of the 2.6.33 merge window (the time during which Linus takes potentially ‘intrusive’ patches to the kernel, followed by a period of stabilisation) and with it a flood of patches intended for the 2.6.33 kernel release…

Sysctls
Linux contains support for various ‘sysctls’ – software tunable knobs that can be used to adjust the behaviour of the kernel at runtime. Traditionally, these were set using both an interface within /proc, or a command-line utility named ‘sysctl’. This resulted in a certain amount of code duplication and a need to support two interfaces, so 2.6.33 contains an update that merges both (internally) into a single /proc interface that is automatically exposed to the sysctl utility via a wrapper on its sysctl system call that makes calls into the /proc files instead. It was probably long since about time.

A lot of other stuff is headed into 2.6.33, including a generic x86 instruction decoder that can really help virtualisation, a switch to fully dynamic per-CPU allocation (now that Tejun Heo has converted the last – IA64 – user from the older static code), and Christoph Hellwig did some work on O_SYNC semantics such that the kernel will now have a real implementation that doesn’t treat all calls to sync file system commits as a heavyweight O_DSYNC call instead.
Meanwhile, outside the merge window…

Asynchronous page faults
As Linux systems are increasingly running massively threaded applications, some of the older and more venerable assumptions in the virtual memory subsystem are being revisited. For one thing, the mmap_sem lock that prevents two threads of the same process from performing certain page table modifications simultaneously, is getting an overhaul. With the latest work on asynchronous page faults, one thread blocking to read in data from disk or from swap should have even less impact on other running threads.

Feature removal
The Linux kernel strives to retain the utmost compatibility between itself and application programs. While almost nothing within the kernel itself is off-limits to those wanting to make changes, the public interface between the kernel and (often not easily recompiled) software that makes use of it is usually considered set in stone. But even then, there comes a time when older features must be retired to make way for newer ones and to avoid supporting legacy code forever. To that end, the kernel documentation contains a file named feature-removal.txt. It was pointed out recently that some items in that file date back to 2005 and it needs a little overhaul of its own to see what it still worth removing and what might continue to be retained to aid backward compatibility.

Performance and debugging support remain strong themes in terms of ongoing kernel development at the moment. Recent work has included additional updates to the ‘perf’ performance tracing command – for example, 2.6.33 will have support for kmem, or kernel memory – use profiling, as well as dynamic ftrace probe-point support, and a number of updates to the generic code now implementing hardware breakpoints (that is known as hw-breakpoints).

Before I go, don’t forget to visit www.kernelpodcast.org for free podcasts on kernel development from me.

This article originally appeared in issue 84 of Linux User & Developer magazine.

Linux User & Developer, one of the nation’s favourite Linux and Open Source publications, is now part of the award winning Imagine Publishing family. Readers can subscribe and save more than 30% and receive our exclusive money back guarantee – click here to find out more.

magfan84

Pages: 1 2
  • Tell a Friend
  • Follow our Twitter to find out about all the latest Linux news, reviews, previews, interviews, features and a whole more.

    2 Comments »

    • mirc said:

      Thanks for the great read, i will be back for sure!.

    Trackbacks

    What's your opinion?

    Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

    Be nice. Keep it clean. Stay on topic. No spam.

    * Required fields