Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #320 For 28 Aug 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1878 posts in 11MB. See the Full Statistics.

There were 577 different contributors. 230 posted more than once. The average length of each message was 95 lines.

The top posters of the week were: The top subjects of the week were:
138 posts in 612KB by ingo molnar
85 posts in 486KB by olaf hering
62 posts in 222KB by lee revell
38 posts in 161KB by russell king
35 posts in 275KB by william weston
194 posts in 840KB for "[patch] i386: selectable frequency of the timer interrupt"
123 posts in 916KB for "[patch] real-time preemption, -rt-2.6.12-rc6-v0.7.48-00"
99 posts in 607KB for "realtime preemption, 2.6.12, beginners guide?"
65 posts in 316KB for "real-time preemption, -rt-2.6.12-final-v0.7.50-24"
24 posts in 107KB for "[patch] ramfs: pretend dirent sizes"

These stats generated by mboxstats version 2.8

1. Linux 2.6.13-rc3 Released; Status Of Default HZ Value

12 Jul 2005 - 21 Jul 2005 (18 posts) Archive Link: "Linux v2.6.13-rc3"

Topics: FS: ReiserFS, Kernel Release Announcement, Ottawa Linux Symposium, Power Management: ACPI, Sound: MIDI

People: Linus Torvalds, Lee Revell, Dmitry Torokhov

Linus Torvalds announced Linux 2.6.13-rc3, saying:

Yes, it's _really_ -rc3 this time, never mind the confusion with the commit message last time (when the Makefile clearly said -rc2, but my over-eager fingers had typed in a commit message saying -rc3).

There's a bit more changes here than I would like, but I'm putting my foot down now. Not only are a lot of people going to be gone next week for LKS and OLS, but we've gotten enough stuff for 2.6.13, and we need to calm down.

Admittedly the diff looks a bit bigger than it really conceptually is, partly due to the hwmon drivers moving around, partly due to re-indenting reiserfs. No real changes, but huge diffs in both cases.

Dmitry Torokhov noticed that he'd been credited with a patch to enable EC Burst Mode in ACPI, while Luming Yu had really done the work. He piped up to give credit where credit was due.

Elsewhere, Lee Revell remarked, "HZ still defaults to 250. As was explained in another thread, this will break apps like MIDI sequencers and won't really save much battery power. The default should remain 1000 until these issues are resolved." But Linus replied:

Stop bothering with this, I've seen the thread, and no, I disagree totally with "as explained in another thread". That's simply not true.

The only thing that is true is that 100Hz is too low for some use, and 1000Hz is too high for some uses. NOBODY has shown that 250Hz isn't good enough, there's only been people whining and complaining and saying it might not be.

The fact is, engineering is about finding something that works "well enough". If _you_ think that 1000Hz is the right answer, then _you_ select that. But if you cannot accept the fact that other people are of a different opinion, then why would anybody want to discuss the issue with you?

This is a fundamental fact of engineering (and, in fact, pretty much any other area in life):

If you cannot accept that other people have other aims and needs than you, then why are you talking to other people in the first place?

So get on with your lives. Realize that there is no "perfect" value for HZ. 250 right now is somewhere reasonable, and for the extreme ends you can always chose your own. Don't try to force your ideas on others.

And btw, the next time somebody complains about HZ, I want HARD DATA. I don't want whining. Stop cc'ing me if you don't have a real datapoint, and if you cannot accept that other people have _other_ real datapoints.

Lee replied, "OK, point taken, I'm done with this issue as far as LKML is concerned. Anyone who wants to discuss this further can come over to the linux-audio-dev list."

2. Patch Review For Linux; Some Developers Unhappy With Acceptance Policies

13 Jul 2005 - 17 Jul 2005 (25 posts) Archive Link: "[00/11] -stable review"

Topics: SMP

People: Greg KH, Francois Romieu, Adrian Bunk, Ralf Baechle

Greg KH announced:

This is the start of the stable review cycle for the release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Friday, July 15, 20:00:00 UTC 2005. Anything received after that time, might be too late.

One of the patches had this changelog entry: "Drivers really only work well in SMP if they actually can be selected. This is a leftover from the time when the 6pack drive only used to be a bitrotten variant of the slip driver." Francois Romieu asked:

Is the guideline above from 28/04/2005 obsoleted ?

Greg replied, "It lets the driver be built, when it previously could not be, unless the user used a config option that almost no one does... That's pretty critical if you ask me." But Adrian Bunk said:

I do agree with Francois regarding this issue:

AFAIR, there has been not one 2.6 kernel where this driver was available for SMP kernels. It's therefore untested which problems might arise with this driver on SMP systems. I'm not arguing against including this driver in 2.6.13, but isn't the right place.

What surprises me most is that you accepted this patch is neither in 2.6.13-rc3 nor in 2.6.13-rc3-mm1. There seems to be either an (IMHO unfortunate) change in your policy of what patches to accept, or there's a serious problem in your patch review process.

Ralf Baechle argued that the patch was good, and that the unavailability of the working driver was justification enough; but there was no further discussion.

3. New Linux Kernel Performance Project

14 Jul 2005 - 15 Jul 2005 (9 posts) Archive Link: "[announce] linux kernel performance project launch at"

Topics: Virtual Memory

People: Kenneth W. Chen, Andi Kleen, Randy Dunlap

Kenneth W. Chen said:

I'm pleased to announce that we have established a linux kernel performance project, hosted at

As much as discussed various time in the past on LKML that Linux kernel needs a systematic and disciplined way to measure and track kernel performance on a regular basis. To do that, we decided to run a large set of benchmarks covering core components of the Linux kernel (virtual memory management, I/O subsystem, process scheduler, file system, network, device driver, etc) on a regular basis. Benchmarks are run on a variety of platforms (4P Intel Xeon processor, 2P Xeon, several ia64 server boxes etc) every week, measuring the latest snapshot of Linus' git development tree. Comprehensive performance data from our tests will be published for easy access.

Our goal is to work with the Linux community to further enhance the performance of the Linux kernel. The data available on the site allows community members to closely track performance gains and losses with every version of the kernel. Ultimately, we hope that this data will result in performance increases in Linux kernel development.

The benchmark result pages are populated with a few benchmarks at the moment. In the coming weeks, we will be populating more benchmark data. Happy surfing and hacking!!

Andi Kleen replied:

That's very cool. Thanks a lot.

Would it be possible to add 2.4.30 numbers and perhaps one or two distro kernels (let's say RHEL3/4, SLES8/9) to the graphs as data points for comparison? These are all very tuned kernels and would show where mainline is worse than them.

Also how did you run netperf? Locally or to some other machine? Perhaps that should be documented.

Some oprofile listings from a few of the test runs would be also nice.

Kenneth replied that they'd decided to go with mainline kernels for consistency, but they'd look into adding distibution kernels as well. Regarding netperf, Kenneth confirmed that it was run locally, and said he'd document that fact. Regarding oprofile listings, Kenneth said, "That is in the works. We will upload profile data. I'm having problem with oprofile on some versions of kernel and that is being investigated right now." Andi said, "If you run statically compiled kernels you could as well use the old style readprofile. It just doesn't work with modules." And Randy Dunlap put in, "It can be made to work with modules (and has been against 2.6.6), but I'd just stick with not using modules, given a choice."

4. Guide To Using git

15 Jul 2005 (1 post) Archive Link: "Kernel Hacker's guide to git (updated)"

People: Jeff Garzik

Jeff Garzik said:

I've updated my git quickstart guide at

It now points to DaveJ's daily snapshots for the initial bootstrap tarball, is reorganized for better navigation, and other things.

Also, a bonus recipe: how to import Linus's pack files (it's easy).

This recipe presumes that you have a vanilla-Linus repo (/repo/linux-2.6) and your own repo (/repo/myrepo-2.6).

$ cd /repo/myrepo-2.6
$ git-fsck-cache                # fsck, make sure we're OK
$ git pull /repo/linux-2.6/.git # make sure we're up-to-date
$ cp -al ../linux-2.6/.git/objects/pack .git/objects
$ cp ../linux-2.6/.git/refs/tags/* .git/refs/tags
$ git-prune-packed
$ git-fsck-cache                # fsck #2, make sure we're OK

This recipe reduced my sync from ~50,000 files to ~5,000 files.

5. Linux Released

15 Jul 2005 - 16 Jul 2005 (3 posts) Archive Link: "Linux"

Topics: Ioctls, Networking, PCI, Power Management: ACPI, SMP

People: Greg KH, Ralf Baechle, David S. Miller, Patrick McHardy, Alexander Nyberg

Greg KH announced Linux, saying:

We (the -stable team) are announcing the release of the kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between and, as it is small enough to do so.

The updated 2.6.12.y git tree can be found at:
and can be browsed at the normal git web browser:


 Makefile                                     |    2
 arch/ppc/kernel/time.c                       |   13 ++--
 arch/um/kernel/process.c                     |   48 ++++++++++-------
 drivers/acpi/pci_irq.c                       |    2
 drivers/char/tpm/tpm.c                       |   76 ---------------------------
 drivers/char/tpm/tpm.h                       |    2
 drivers/char/tpm/tpm_atmel.c                 |   16 +++--
 drivers/char/tpm/tpm_nsc.c                   |   16 +++--
 drivers/char/tty_ioctl.c                     |    4 -
 drivers/media/video/cx88/cx88-video.c        |    2
 drivers/net/hamradio/Kconfig                 |    2
 drivers/net/shaper.c                         |   40 +++++---------
 fs/char_dev.c                                |    2
 include/linux/if_shaper.h                    |    2
 net/ipv4/ip_output.c                         |    3 -
 net/ipv4/netfilter/ip_conntrack_standalone.c |    7 ++
 net/packet/af_packet.c                       |    6 ++
 17 files changed, 93 insertions(+), 150 deletions(-)

Summary of changes from v2.6.12.2 to v2.6.12.3

Alexander Nyberg:
If ACPI doesn't find an irq listed, don't accept 0 as a valid PCI irq.

David S. Miller:
fix Shaper driver lossage in 2.6.12

Greg Kroah-Hartman:

john stultz:
ppc32: stop misusing ntps time_offset value

coverity: tty_ldisc_ref return null check

Kylene Jo Hall:
tpm breaks 8139cp

Michael Krufky:
v4l cx88 hue offset fix

Paolo 'Blaisorblade' Giarrusso:
uml: fix TT mode by reverting "use fork instead of clone"

Patrick McHardy:
revert nf_reset change

Ralf Baechle:
SMP fix for 6pack driver

Wen-chien Jesse Sung:
fix semaphore handling in __unregister_chrdev_region

6. Some Advice For New Kernel Hackers

18 Jul 2005 - 19 Jul 2005 (8 posts) Archive Link: "how to be a kernel developer ?"

Topics: FS: NFS

People: Jesper Juhl, Brian O'Mahoney, Alessandro Rubini, Jonathan Corbet, Robert Love

Someone asked about how to be a kernel developer, and several folks replied with suggestions. Jesper Juhl said:

A few things you should do :

He added in another email:

You can also help out by testing the development kernels - they need testing by as many people as possible, so start testing the -rc kernels and the daily git snapshots as well as the -mm kernels. Test if they build with your usual configuration, test if they build with "allnoconfig", "allyesconfig", "allmodconfig" and perhaps a random config or two. Test if they boot OK, if they run OK for a longer time, etc.

When you find a problem you can try to fix the issue yourself and send a patch to both the mailinglist and the person responsible for the code in question. If you are unable to fix the problem yourself, then send a detailed bugreport to the list and the person responsible for the code. Take a look at the REPORTING-BUGS file in the kernel source dir and the Documentation/BUG-HUNTING file.

Helping to test pre-release kernels is a valuable effort. Run a new kernel daily :-)

Brian O'Mahoney replied that he agreed with Jesper's advice, with some caveats:

please do NOT debug kernel mods on your 'main-box', where your filesystems live. unless you like to live dangerously and make perfect backups you don't mind spending lots of hours restoring,

unless you want to specialise in file systems, but maybe do want to work on device drivers use a ---

sacrifical system, and, for example NFS mount everything, on it from your main box, otherwise use a cheap local disk just for your fs stuff

then when you blow it there is no FS damage and you don't need to wait for FSCK, or Journal Replay, when your fs works you can live more dangerously ;-)

You will also need a main system, and serial X-over cable, if you want to use some of the increasing number of tools,

kdb, kgdb, kprobes .... that assume a 2 box setup

Finally, Linus personally dislikes debuggers, ... 'read the source Luke' so patches to the mm or mainstream should be grounded an source code analysis, not it works or xxx has 0x1234 in it.

Jesper agreed that "A sacrificial box or at least proper backups of any important stuff is important. I didn't write that since I figured it to be obvious, but I guess I should have spelled it out anyway. Thank you for making that bit clear :-)"

7. DevFS Author Speaks In Favor Of DevFS After Long Silence

18 Jul 2005 (4 posts) Archive Link: "Re: [GIT PATCH] Remove devfs from 2.6.12-git"

Topics: BSD: FreeBSD, FS: devfs, FS: sysfs

People: Richard Gooch, Jan Engelhardt, Jim Crilly, Alexander Viro, Daniel Phillips, Greg KH

With all the discussion of removing DevFS from the kernel, its original author Richard Gooch made a brief appearance, the first in years. He responded very briefly to several of Greg KH's recent statements, but didn't stick around for an argument.

Greg had said that Richard had stated that udev was a proper replacement for DevFS. Richard replied, "Well, that's news to me!"

Greg had also said that DevFS should be taken out because policy should exist in userspace and not in the kernel. Richard pointed out that SysFS, developed in large part by Greg, also implemented policy in the kernel.

To Greg's assertion that DevFS represented clutter and mess, Richard said this was really in the eye of the beholder.

And to Greg's statement that DevFS was broken and unfixable, Richard simply said, "No proof. Never say never..."

Jan Engelhardt asked where Richard had been all this time, if he expected DevFS to be maintained and kept in the kernel. Daniel Phillips replied that Alexander Viro had chased him out with relentless attacks.

Jan also said in his email, "Something's wondering me, though: FreeBSD "just" (5.0) introduced devfs, so either they are behind The Facts (see udev FAQ), or devfs (anylinux/anybsd) is not so bad after all." Jim Crilly replied, "There's not much to wonder about here, the basic idea of devfs is a good one which is why udev was written. The problems expressed on lkml about devfs were with that specifically implementation, if a better implementation had been merged originally udev might have never been created. I really doubt FreeBSD took the Linux devfs code and integrated it with their kernel, so the fact that FreeBSD is using a devfs now simply means they like the idea of a dynamic /dev as well."

8. New patchview Script For Better Review

20 Jul 2005 (1 post) Archive Link: "[announce] 'patchview' ver. 002"

People: Randy Dunlap

Randy Dunlap said:

'patchview' merges a patch file and a source tree to a set of temporary modified files. This enables better patch (re)viewing and more viewable context. (hopefully)

The patchview script is here:

usage: patchview [-f] patchfile srctree {ver. 002}
  -f : force tkdiff even if 'patch' has errors
  -s : single tkdiff even if patchfile contains multiple files

It uses (requires) lsdiff (from patchutils) and tkdiff.


Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.