Con Kolivas (of SD/BFS fame) has posted his thoughts on the new ~200 line “miracle” kernel patch. It’s an interesting read.
In short, he had already implemented something like this in a 10 line patch to his BFS scheduler, but he dropped them because it introduced regressions.
Those following the development of the patches for interactivity at massive load, I have COMPLETELY DROPPED them as they introduce regressions at normal workloads, and I cannot under any circumstances approve changes to improve behaviour at ridiculous workloads which affect regular ones. I still see precisely zero point at optimising for absurd workloads. Proving how many un-niced jobs you can throw at your kernel compiles is not a measure of one’s prowess. It is just a mindless test.
He goes on to say:
Again, I can’t for the life of me see why you’d optimise for make -j64 on a quad core machine. It is one workload, unique to people who compile all the time, but done in a way you wouldn’t normally do it anyway. It is not going to magically make anything else better. If for some god-forsaken reason you wanted to do that, you could already do that with nice, or even better, by running it SCHED_IDLEPRIO.
Perhaps this patch really helps the existing CFS implementation, but it’s still lacking when compared to BFS. Maybe it is a step in the wrong direction, but perhaps some improvement like this is better than none at all? It might be the catalyst needed to improve the kernel further. I never could understand why we couldn’t have more than one CPU scheduler in the kernel (like we do for block I/O).
Anyway, this is all quite interesting!
-c
One thought on “Con Kolivas posts his thoughts on the new ~200 line kernel patch”