KVM. Not to be outdone by the tremendous volume of upstream Xen postings we have seen this week, Avi Kivity posted a series of KVM fixes against the 2.6.30-rc3 kernel. Perhaps the most interesting of these is the removal of guest access to Intel IO port 0x80. Historically, Operating Systems such as Linux have used trivial writes to port 0x80 (also know as the "debug port"), since these usually take a predictable number of processor cycles to complete, and can therefore be used in order to implement delay routines within the core kernel. However, some recent systems have had issues in which writes to hardware port 0x80 cause a hard lockup instead. Needless to say, this is less than ideal - especially when its potential risks cannot be adequately detected in an automated fashion - and has resulted in much less reliance on such "old school" style hacks by later kernels.
Xen. Jeremy Fitzhardinge posted an interesting analysis performed by Intel of the performance hit of using the paravirt_ops interface provided by recent kernels for para-virtualization purposes. Apparently, much of that overhead comes from paravirtualized spinlocks. To quote Jeremy, "the extra call/return in the spinlock path is somehow causing an increase in the cycles/instruction of somewhere around 2-7% (seems to vary quite a lot from test to test). The working theory is that the CPU's pipeline is getting upset about the call->call->locked-op->return->return, and seems to be failing to speculate)". On another virtualization note, Izik Eidus posted an update to the KSM API moving away from ioctls and instead toward madvise.
Hibernate. Rafael J. Wysocki posted the 4th version of a patch series aimed at reworking memory shrinking on hibernate. Shrinking (of virtual memory) is used in order to make room for the storage of the resultant hibernate image file within the system swap area. The patch series notices and corrects a needless shrinking of memory on systems suspending to RAM instead of to disk, since in the case of suspend to RAM, the RAM contents are preserved.
Forced CPU evacuation. Vaidyanathan Srinivasan posted version two of his patch series aimed at forced CPU evacuation. The basic premise is that, on sufficiently lightly loaded systems, a tradeoff can be made in which tasks are forced to migrate away from certain cores that will be kept idle in order to save power. This can be used in combination with CPU frequency regulation governors, thermal management (moving away from hotter cores), and other recent energy saving innovations.
Hardware breakpoints. K. Prasad posted a patch series aimed at overhauling hardware breakpoint management. The work was originally done for the benefit of the ftrace tracing subsystem, and introduces various new structs - including a struct named hw_breakpoint - intended to generalize the creation and management of hardware breakpoints rather than having code touch the CPU registers that provide this interface directly. This allows for wider, conflict free in-kernel hardware breakpoint usage. These patches touch ptrace, ftrace, and process handling.
MEMORY_HOTPLUG_RESERVE. Yinghai Lu pointed out that historically, x86_64 had an architectural specific method for memory hotplug whereby it scanned the SRAT (Static Resource Affinity Table - part of the ACPI spec) for physical memory ranges that could by used for memory hot-add later. Those without physical memory would then be prepared for later additions by adding entries in the global memmap ahead of time. This depended upon DISCONFIG, which has now been removed, and so the HOTPLUG_RESERVE feature is now "dead".
asm-generic headers. Arnd Bergmann posted version 4 of a patch series aimed at cleaning up the asm-generic headers. The cleanups include the renaming of some core generic assembly files - e.g. signal.h, atomic.h, page.h, and uaccess.h. Arnd requested that Stephen Rothwell pull these changes into his next linux-next, while soliciting feedback on whether to send these patches to Linus, or whether there was a subsystem maintainer to target.
Stephen Rothwell posted a linux-next for May 13th. Since Tuesday, the vfs tree gained a conflict against the ext4 tree, the block tree gained a build failure due to interactions with the scsi tree, for which Stephen reverted the affected commit and applied a patch. The kmemleak tree required one less merge fix, the driveir-core tree lost its build failure. Finally, two patches were needed for runtime problems in the net tree. Stephen added them in order to avoid holding up testing, but cautions that a proper fix will be needed in the net tree.