Re: [PATCH] Nick's scheduler policy v12

[Jörn Engel]

On Fri, 5 September 2003 20:36:32 -0700, Martin J. Bligh wrote:
> 
> Well, if I can be naive for a second (and I'll fully admit I don't
> understand the implications of this), there are two things here - 
> either give it more of a timeslice (bandwidth increase), or make it 
> more interactive (latency increase). Those two seem to be separable,
> but we don't bother. Seems better to pass a more subtle hint to the
> scheduler that this is interactive - nice seems like a very large
> brick between the eyes.

Just as naïve as you, Martin, but your idea is at least incomplete.
We have to make some processes behave differently, right, but we also
have to detect, which ones they are.  Is the user unhappy with gcc
being a bit jerky?  No, so gcc is not a problem.  X, xmms, xine,
mplayer, quake and a thousand more make the user unhappy, but how do
we detect them and only them?  And which ones do we favor if several
are competing?

One way is to let the user tell you, through nice or anything else,
but the user doesn't want to, so that is suboptimal.

Another way is to integrate the GUI into the kernel, so you know which
window is on top, etc.  But we surely don't want that.

A third way may be to accept hints from userspace, so that X can tell
us, which window is on top.  Maybe as a last resort.

What remains is to try to detect the "interactive" processes through
their behaviour and I am not sure if it is possible to always get this
right in the general case.

Detecting the right processes is the real problem, Martin.  If you can
do that, the rest is quite simple.  And so far, we are quite bad at
it. :(

> I'm probably missing something ... feel free to slap me ;-)

*slap*
Maybe you didn't offer me to, but it still felt good. :)

Jörn

-- 
Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/