[lkml]   [2003]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Nick's scheduler policy v12
    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 ;-)

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


    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:48    [W:0.026 / U:85.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site