[lkml]   [2003]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Nick's scheduler policy v12

    Martin J. Bligh wrote:

    >>I think the two will always related. One means giving a higher
    >>dynamic priority, the other a bigger timeslice. So you want
    >>say gcc to have a 100ms timeslice with lowest scheduling prio,
    >>but X to have a 20ms slice and a very high scheduling priority.
    >>Unfortunately, the way the scheduler currently works, X might
    >>use all its timeslice, then have to wait 100ms for gcc to finish
    >>its. The way I do it is give a small timeslice to high prio tasks,
    >>and lower priority tasks get progressively less.
    >If the interactive task uses all it's timeslice, then it's not really
    >very interactive, it's chewing quite a bit of CPU ... presumably in
    >the common case, these things don't finish their timeslices. I thought
    >we preempted the running task when a higher prio one woke up, so this
    >should still work, right?

    No, you are _very_ right about that.

    >So it would seem to make sense to boost the prio of a interactive task
    >*without* increasing the size of it's timeslice.

    Well, what I do is boost their priority and make the timeslices of non
    interactive apps smaller. And sometimes they do need small bursts of
    using a lot of cpu.

    >>When _only_ low priority tasks are running, they'll all get long
    >That at least makes sense. AFIAK at least the early versions of Con's
    >stuff make cpu bound jobs' timeslices short even if there were no
    >interactive jobs. I don't like that (or more relevantly, the benchmarks
    >don't either ;-)).
    >>OK well just as a rough idea of how mine works: worst case for
    >>xmms is that X is at its highest dynamic priority (and reniced).
    >>xmms will be at its highest dynamic prio, or maybe one or two
    >>below that.
    >>X will get to run for maybe 30ms first, then xmms is allowed 6ms.
    >>That is still 15% CPU. And X soon comes down in priority if it
    >>continues to use a lot of CPU.
    >If it works in practice, it works, I guess. I just don't see why X
    >is super special ... are we going to have to renice *all* interactive
    >tasks in order to get things to work properly?

    The reason X is special is that it uses a lot of CPU, and it can be
    continually using a lot of CPU, but it is "interactive" - it probably
    requires the lowest scheduling latency of any other interactive process
    because it runs the mouse, screen, keyboard etc, things that obviously
    can't make use of much buffering, if any.

    If you wanted X to be treated as any other process, thats fine, use
    renice 0. It will be given low priorities when using lots of CPU

    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.023 / U:186.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site