Linux scheduling - Journal of Omnifarious
Jul. 31st, 2007
02:34 pm - Linux scheduling
I was reading this article on Slashdot about Linux scheduling and I had some interesting thoughts after reading the LKML thread in which people complain about the new scheduler's impact on games.
It was clear to me after reading that thread that the kernel developers were inappropriately obsessed with throughput measures like game framerates and such. The real measure you want is latency. And even latency isn't enough, you want to know both the average latency between user input and the user interface (or game) reacting, and you want to know the standard deviation of the latency between input and reaction. I posted these two bits of text about this:
First, this one complaining about throughput:
FPS is a poor measure of the feel of a game. I know it's what all the graphics card benchmarks use, and it does do a good job of measuring the total processor and video card throughput, but that's not the most important thing.
The most important thing is the time between you pressing a key and the changed game state being reflected on your screen and how consistent that delay is.
One of the arguments that CK has made about kernel development is that kernel developers have become obsessed with throughput to the exclusion of all else and that this leads to very poor desktop performance because throughput is a poor measure of 'interactivity'. Someone posting 3D game framerates as evidence of one scheduler being better than another is exhibiting exactly this bias.
IMHO latency is a better measure, but still not perfect and it can be hard to measure in some cases.
I don't know enough about the scheduler to know which one is better or which one exhibits particular properties. But I can see that the throughput bias is evidenced in force in the thread the article points to.
And CK is also right that big iron shops care more about overall throughput than any measure of 'interactivity'. IMHO there ought to be some kind of pluggable scheduler system that allows you to completely change the algorithm to reflect the preferred behavior of the computer you're using.
And then this post in which I outline why even average latency is inadequate:
It's also good if the delay is of a consistent length. You can adapt to a fixed delay if it's small, but it's really hard to adapt to a delay that's jumping all over the place even if on average it's pretty small. Additionally an inconsistent delay length leads to things looking choppy even when the delays are all fairly small.
If you moved a window across a screen and at a particular speed and its position was updated at a fairly consistent once every 2 pixels it would still look pretty darn smooth, but if it sometimes updated every pixel and sometimes every 3 or 4 it would look pretty choppy even if on average it only moved 2 pixels per update.
Having the delay be inconsistent also messes with the feedback between what you see on the screen and how fast you move your mouse.
In short measures like throughput or even just average latency are pretty poor. What you want is a measure of real feedback latency and look at both the average, standard distribution and outliers in various load situations. I suspect what you want a very tight cluster around an average latency and as load goes up you want that average to degrade gracefully while the cluster remains relatively tight.