Log in

No account? Create an account

Linux scheduling - Journal of Omnifarious

Jul. 31st, 2007

02:34 pm - Linux scheduling

Previous Entry Share Next Entry

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.

Current Mood: [mood icon] contemplative


Date:August 2nd, 2007 08:50 pm (UTC)

Fix it then

Like most performance-oriented people, I think Linux kernel developers like objective quantitative measures. You say they should look at "both the average, standard distribution and outliers in various load situations"? How should they do that? Make a test program that produces these numbers, then tell them about it.
(Reply) (Thread)
[User Picture]
Date:August 3rd, 2007 04:33 am (UTC)

Re: Fix it then


I realize that, and the thing I'm happiest about in my posts is coming up with what I think is a good quantitative measure. Yes, I could do that one better by actually making that measurement for a few important applications, but I don't think that the fact I haven't done so makes posting about the idea pointless. Not that you're saying it is, but you seem quite irritated that I've posted this and not actually done the measurement.

(Reply) (Parent) (Thread)
Date:August 3rd, 2007 05:08 am (UTC)

Re: Fix it then

I just don't think you've defined it well enough to measure it. Prove to me that it exists before you complain people aren't using it.
(Reply) (Parent) (Thread)