LKML Summary Podcast

Audio: http://media.libsyn.com/media/jcm/linux_kernel_podcast_20090902.mp3

For Wednesday, September 2nd, 2009, I’m Jon Masters with a summary of today’s LKML traffic.

In today’s issue: Fsync, memory controller groups, and tree RCU scalability.

Fsync. Christoph Hellwig noticed that there is a disconnect in necessary fsync handling between older and newer filesystems. Many modern filesystem only update and write out metadata once other IO commits have taken place. They sometimes implement a wait inside their ->fsync methods but this is suboptimal because it happens under the i_mutex lock and must wait for an entire file to be flushed out. Instead, it can be preferable to simply wait for data writeout completion within O_SYNC handling prior to calling ->fsync. This is what Christoph’s patch does in modifying vfs_fsync_range. He includes a mini-audit of the impact upon existing filesystems and any necessary actions.

Memory cgroups. Kamezawa Hiroyuki notes that there are a few scalability issues with the current res_counter charge and uncharge accounting functions in the memory controller groups code, especially lock contention. He believes that there is a chance to perform batch-uncharge by building up a list of pages that have been affected by paging and accounting them at the time when other large chunks are processed (as a result on unmapping, truncation, at task completion, and so forth). Since it is late in the 2.6.31 cycle, he is willing to wait until the floodgates have opened for 2.6.32. Separately, Kamezawa also cleaned up multiple calls to res_count_soft_limit_excess.

Tree RCU scalability. Nick Piggin posted saying that he is testing out the scalability (or lack thereof) of various VFS code paths, and that he is noticing a problem with call_rcu. According to Nick, __call_rcu is taking 54 times more CPU to do 8 times the amount of work from 1-8 threads, of a factor of 6.7 slowdown when using tree RCU. Nick obviously requested further information from Paul McKenney, RCU inventor and chief guru.

In today’s miscellaneous items: some further fake numa node creation patches for powerpc from Ankita Garg, version 17 of the per-bdi writeback flusher threads patches from Jens Axboe, version 4 of a patch making O_SYNC handling use the standard syncing path from Jan Kara, some x86 performance counters updates from Markus T. Metzger, an updated version of the previous days’ walltime clock synching patches for KVM guests from Glauber Costa, full NAT support for IPVS with netfliter matching support from Hannes Eder, a rework of the GPE handing in the ACPI code from Matthew Garrett, additional warnings within Documentation/md.txt (largely fueled by Pavel Machek’s ongoing rants about RAID support), a summary of merge plans for RDMA in 2.6.32 from Roland Dreier (who suspects rc8 signals impending merge window craziness), some performance counters fixes for POWER7 support from Paul Mackerras, and Luis R. Rodriguez wondered whether kmemleak.h really needed to be exported to userspace.

Finally today, Frederic Riss questions whether ARM kprobes unregistration is SMP safe. The current code makes use of an illegal unstruction to trigger the kprobe code, and Frederic cannot see how one avoids a situation in which a probe is being unregistered as another core takes an illegal instruction. He wonders whether stop_machine should be in use instead.

The latest kernel release was 2.6.31-rc8.

Inotify continues to be a pain upstream. Tej Bewith posted a git dissection in which he claims that a recent fix from Eric W. Biederman to ensure for NULL termination actually broke his system from booting.

Maciej Rutecki posted a potential regression against USB in 2.6.31-rc8. Apparently, since rc7, a Debian testing box experiences unreliable detection and handling of plugin flash drives on KDE4 (one assumes with identical userland between the two kernels).

Wu Zhangjin discovered a kernel panic on 2.6.31-rc7-rt8 in the SetPageLRU code, running on MIPS.

Stephen Rothwell posted a linux-next tree for September 1st. Since Tuesday, the tree gained a few build failures (xfs, acpi, v4l-dvb, net, block). The total subtree count remains steady at 141 trees in the current compose.

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