Kernel Traffic #320 For 28 Aug 2005

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.

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.

This is the start of the stable review cycle for the 2.6.12.3 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 stable@kernel.org 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.

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

• It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.

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

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

http://kernel-perf.sourceforge.net

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!!

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.

I've updated my git quickstart guide at

http://linux.yyz.us/git-howto.html

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 kernel.org sync from ~50,000 files to ~5,000 files.

We (the -stable team) are announcing the release of the 2.6.12.3 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 2.6.12.2 and 2.6.12.3, as it is small enough to do so.

The updated 2.6.12.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

----------

 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:
Linux 2.6.12.3

john stultz:
ppc32: stop misusing ntps time_offset value

KAMBAROV, ZAUR:
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

A few things you should do :

• Take a look in the Documentation/ directory in the kernel source, you'll find lots of valuable information there.
• Go check out http://kernelnewbies.org/
• You may also find this online source browser useful (I know I do) http://lxr.linux.no/
• Keep a link to a LKML archive in your bookmarks and search the archives for answers whenever you have a question - chances are good that whatever you want to ask has been asked before and answered in depth on the list, so it'll be in the archives. Here's one LKML archive you can use, it goes back a few years : http://www.ussg.iu.edu/hypermail/linux/kernel/
• Subscribe to LKML and start reading the some of the threads. A lot can be learned by reading the bugreports and solutions that pop up on the list, there are also often discussions on ideas, implementation details, debugging etc etc that can be valuable. So join the list and start listening :) ohh, and do read the lists FAQ at http://www.tux.org/lkml/
• You may also want to join the Linux Kernel Janitors http://janitor.kernelnewbies.org/ - they have a mailing list and a nice TODO list of things that need doing - good place to pick a small starting project from.
• You should also, most likely, invest in a few books on the kernel and read them. I'd recommend these two as good ones to start with : "Linux Kernel Development (2nd Edition), by Robert Love" and "Linux Device Drivers (Third Edition), by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman".
• And most important of all, start reading the kernel source, and play with the kernel source. Reading the source, making some changes and then testing them and learning from the mistakes you make is a great way to learn.

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 :-)

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.

'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: http://www.xenotime.net/linux/scripts/patchview

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.

patchutils: http://cyberelk.net/tim/patchutils/
tkdiff: http://sourceforge.net/projects/tkdiff/