Zack's Kernel News
Zack's Kernel News
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.
Saving Power With Idle CPUs
Arun R. Bharadwaj is working on CPUidle, a project to make sure that idle CPUs on a given PowerPC system are put into the most appropriate power usage state in a clean and efficient way. For example, it's not necessarily obvious whether a CPU is going to be idle long enough to warrant putting it into a very low power state, from which it would take longer to make it available to the system again if it's needed. CPUidle relies on various heuristics to guide it in making that selection. CPUidle currently chooses between only two idle states – a snooze or a full-fledged nap. No kidding, that's what they're called. CPUidle is the kind of project that starts off relatively simply and then gradually introduces additional idle states to accommodate newer and newer processors, with more and more complicated heuristics used to choose from among them. Typically one might expect such a situation to become very crufty and esoteric over time, until some freak like Alan Cox comes along and completely redoes it to make it much simpler and better. Alternatively, multiple freaks could implement competing improvements, leading to no agreement and tons of fighting until Linus Torvalds does it his own way and the fighting subsides again. CPUidle seems like that type of project to me.
VMware Deprecates Paravirtualization Features
VMware has decided to stop supporting VMI, their paravirtualization technique, because virtualization features in hardware are starting to be the default for all new systems. The announcement from Alok Kataria of VMware gave the benchmark results, which showed that the hardware virtualization was better than their VMI implementation. The reason for his post was to ask for advice about the best way to retire the VMI code, which had been accepted into the kernel already.
Chris Wright explained that typically there would be a deprecation phase, listing the feature in Documentation/feature-removal-schedule.txt and giving run-time alerts that inform the user they're using a deprecated feature. But Jeremy Fitzhardinge pointed out that VMI wasn't so much a feature as an optimization, and beyond the slight speed difference, users would probably not even notice its absence. This made sense to Chris, and because the code was very specific to VMware, he didn't think it would be essential to follow normal deprecation procedures. Also, Jeremy pointed out that removing VMI would be a simple matter of just taking out a couple of files, as opposed to making massive changes in many different places, Greg Kroah-Hartman felt it would be fine to just go ahead and do that.
However, just as Alok posted the patch that would do this, Ingo Molnár objected that a proper sunset period was really what they should undertake. He pointed out that most VMware users weren't yet benefiting from the hardware improvements that made VMI obsolete. Until they did, he wanted to keep the VMI optimization available, even though it wasn't as good as the hardware versions that VMware predicted would be ubiquitous in 2011.
Alok was fine with this and posted patches to go through the regular deprecation process. But just as he did so, H. Peter Anvin said it seemed much too early yet to consider this. Alok's patch was for 2.6.32; Peter felt it would be better to wait until the end of 2010 or (he estimated) kernel 2.6.37.
Gradually, a deprecation plan developed involving a very gradual approach that would leave VMI in the kernel until it could be assumed that users might be migrating their hardware over to systems that had hardware virtualization features.
VMware was acting the good citizen in these code deprecation and kernel development processes. Open source development often includes this type of zeroing in to a solution on the basis of a number of participants' sense of what should be done.
Greg Kroah-Hartman has taken over maintainership of the TTY layer, which had previously been orphaned. He won't be using Git for development, however – he's chosen to rely on quilt, Andrew Morton's patch management tool. The TTY layer handles all serial connections and, basically, any time you have a shell prompt. These types of important elements of the kernel don't tend to change too much over time but should be maintained anyway.
Avi Kivity recently announced that he'd taken on Marcelo Tosatti as co-maintainer of the KVM code. In a departure from the way these things usually happen, they've decided to split up the maintainership duties week by week, with Avi handling incoming patches one week, then Marcelo doing it for a week, and so on. This would leave each of them free to focus on their own coding projects (or as Avi enthusiastically put it, go to the beach) on their off weeks. KVM lets users create any number of virtual machines on a single system, each of which can run Linux or Windows or provide a variety of other environments.