LKML Summary Podcast

Audio: COMING SOON

For Monday, December 14th, 2009, I’m Jon Masters with a summary of today’s LKML traffic.

In today’s issue: cpu_clock, first time posting, ponies, and the VM.

cpu_clock. David Miller and Peter Zijlstra debated cpu_clock() and how NMI safe it may or may not be. Apparently, on SPARC systems (where multiple IRQ levels can exist), David emulates a kind of NMI through running code at different IRQ levels (14 and 15), but that approach isn’t safe with respect to regular calls to local_irq_save/restore because those also affect IRQ level. David thinks it’s a bug to be calling those functions from cpu_clock in the first place and that the code isn’t fully NMI safe, while Peter is not sure. David took the time to also provide a number of useful insights for how various platforms might usefully help to fix cpu_clock.

First time. Someone called Masa started a mail thread entitled “How to upload our driver to “kernel.org” in which they requested advice from the community concerning the best way to work with them in getting their driver into the official kernel, refered to as “kernel.org” in the email message. Several people provided pointers to documentation contained within the kernel source in the “Documentation” directory.

Ponies. The nouveau code finally having been merged (in a thread entitled “drm nouveau pony for Xmas” posted by Dave Airlie), various comments were made, including a success report from Benjamin Herrenschmidt, who was able to specify the correct additional firmware bits (nouveau in-tree has been modified to use the standard kernel request_firmware infrastructure) via CONFIG_EXTRA_FIRMWARE_DIR and CONFIG_EXTRA_FIRMWARE for one of his PowerPC systems. He posted an (big) endian fix for the 6600-series chipset. Dave took the time to followup with his assertion that he would post the VMWare DRM driver to the staging tree next by posting the code for the staging tree.

VM. Rik van Riel and Mincham Kim had a conversation about the behavior of the page reclaim code when there are a large number of tasks active in the reclaim code. Lock contention is one issue, but so is the reclaim algorithm attempting to free up to SWAP_CLUSTER_MAX pages per task. Then there is the issue that Mincham was concerned about, namely that heavy VM pressure coupled with a large number of tasks in reclaim could result in a large number of tasks in NR_UNINTERRUPTIBLE and thus a subsequent OOM would target innocent others. Rik posted a patch limiting the number of tasks allowed to be running page reclaim code from a given memory zone simulataneously to 8.

In today’s announcements: Linux 2.6.31.8 and 2.6.32.1. Greg Kroah-Hartman announced the release of the latest stable kernel versions. These are based on patches that Greg had posted over the previous weekend, and included a large number of ext4 updates, amongst other things.

The latest kernel release is 2.6.32.

These is a report of incorrect atimes being generated for files from Petr Titera.

Stephen Rothwell posted a linux-next tree for December 14th. Since Friday, the net-current tree lost its conflict, the md-current tree gained a conflict against Linus’ tree, the 52xx-and-virtex tree gained a build failure for which Stephen applieda patch, the pci tree lost its conflicts, the kbuild tree lost its merge fix, the acpi tree gained a build failure so the version from Friday was used, the cpufreq tree lost its conflict, the devicetree tree gained a build failure for which Stephen reverted several commits, the limits tree gained 3 conflicts against Linus’ tree, the omap_dss2 tree lost its conflict, the percpu tree gained a conflict against the tip tree, the tty tree lost its conflict, the usb tree lost its conflict and build failure, and the staging tree lost its conflicts, while Stephen repeated his usual “call for calm”, asking that readers not post 2.6.34 patches until after 2.6.33-rc1. The total subtree count remained unchanged at 155 trees for Monday.

Finally today, Linus Torvalds ranted a little in response to Rafael J Wysocki’s latest asynchronous suspend/resume patches, suggesting that Rafael is “overdesigning” the API, and that “[t]o a first approximation, THE ONLY THING THAT MATTERS IS USB”. That maybe true, but a generic interface will certainly provide for longer term alternatives also.

That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.