cpusets, isolcpus, cgroups, Oh My!

Christopher Lameter wanted to restrict new process threads to just a subset of the CPUs installed on a system. This approach would allow real-time software to monopolize certain CPUs and, thus, guarantee their low latency requirements. He posted a patch to implement this at a very early stage of the boot cycle, so that the init process wouldn't start up user daemons on the wrong CPUs.

Gilad Ben-Yossef was very excited about this, but he didn't like the sheer number of parameters that users needed to set in order to use the feature. He suggested that folding Christopher's feature into the existing isolcpus feature might make this simpler. The isolcpus is a mechanism for removing specified CPUs from the scheduler's awareness and letting them run in isolation.

But, as Mike Galbraith pointed out, the isolcpus feature was going to be taken out of the kernel at some point in favor of the existing cpusets feature. Like isolcpus, cpusets lets the user hew off sets of CPUs (and associated regions of memory), so they can run in isolation from the rest of the system.

Gilad was in favor of cpusets taking over from isolcpus because he thought the cpusets feature was more elegant. He pointed out, however, that cpusets couldn't quite do what Christopher's patch attempted, for example, migrating a running timer from one CPU to another. He wouldn't mind seeing Christopher's code folded into cpusets instead of isolcpus, as long as something allowed the kind of workloads he was interested in.

One thing isolcpus could do that cpusets couldn't – and that Christopher's code tried to handle – was come into effect earlier in the boot cycle. Thus, Gilad also suggested reimplementing isolcpus so that all it did was configure cpusets earlier in the boot process.

Mike liked this idea, but Christopher said, "isolcpus is broken as far as I can tell. Let's lay it to rest and come up with a sane way to configure these things. Autoconfig if possible."

Christopher also mentioned that cpusets was going to be replaced by cgroups, a Google project to implement generic resource limitation and isolation.

The discussion veered off at this point to a consideration of how best to migrate threads off of a CPU. For example, what if you identify all the threads to migrate, and then one of them spawns a new thread before you can migrate it off the CPU? If a clean kernel solution exists, would it still be better to do it more messily in userspace? What are the various race conditions that might arise? And, how can the kernel support people in the finance industry who want as close to raw hardware access as possible?

No definitive conclusions were reached on the mailing list – just a very fun discussion and debate. It seems clear, however, that there are currently several different attempts to do the same thing in the kernel; some will go away, while one will (hopefully) gather together the best ideas of the rest.

Developer Backups

Linus's hard drive crashed suddenly one day, costing him some time and a few days of work. He planned to try to recover some of the data, but he said, "If worst comes to worst, I'll just do the last next days of the merge window on the laptop that I was planning on finishing it off with anyway, since I have travel coming up. At least this didn't happen at the very beginning of the merge window."

John Stoffel suggested using two drives and mirroring them. This way, if either of them died, the other would allow a quick recovery. Linus replied, "I long ago gave up on doing backups. I have actively moved to a model where I use replaceable machines instead. I've got the stuff I care about generally on a couple of different machines, and then keys etc backed up on a separate encrypted USB key."

H. Peter Anvin remarked, "I won't get any stationary machines without mirrored drives anymore. Storage just isn't reliable enough." John also said, "And I won't trust a single USB thumb drive to hold my most important stuff. And how do you hold onto family pictures and such? It's amazing how much crap can accumulate, but also how important it can be to have good backups that are remote. If the house burns down, don't matter how many machines the stuff is spread across if it's not local."

That's it. No kernel discussion, just some ideas about backing up one's system.

H8/300 Architecture Going Away

Guenter Roeck suggest that "H8/300 has been dead for several years, the kernel for it has not compiled for ages, and recent versions of gcc for it are broken. It is time to drop support for it."

He posted a patch to delete all associated files, but he also acknowledged that "it is not that simple to drop an architecture, and it may need some discussion, but someone has to put a stake into the ground. Keeping a virtually dead architecture on life support takes resources which are better spent elsewhere."

Greg Kroah-Hartman gave his blessings to this patch, remarking, "If this doesn't build, and no one is using it anymore, I agree, it should be removed. If someone wants to revive it, 'git revert' works just fine."

Joe Perches added the maintainer Yoshinori Sato to the CC list, just in case there was a plan or a hope to revive the architecture at some point. Guenter mentioned that he'd done that as well but possibly had misspelled the email address.

David S. Miller also agreed with Greg and Guenter – the code should go. He gave his "Acked-by" alongside Greg's. Wim Van Sebroeck gave his "Acked-by" as well.

In terms of scheduling, Guenter said: "My plan is create a branch on my repository on kernel.org, ask Stephen to add it to linux-next, and then ask Linus to pull it after one release cycle (ie for 3.13). This should give people enough time to find out about it and complain, and give everyone else enough time to find any missing pieces."

Linus Torvalds said: "I'm ok with code deletion patches, I don't think that would be a problem. I didn't check them, but I assume this is all literally just removing code that is conditional on h8/300 config options?"

Geert Uytterhoeven suggested waiting and hearing from Yoshinori. Geert said Yoshinori had planned to come to the Kernel Summit, so there would be a chance to discuss it directly.

It's very unusual to drop a whole architecture from the kernel. Even in this case, where it wouldn't even compile and had been broken for a long time, there was a reluctance to remove the code without making every effort to confirm that the code truly was dead.