Re: [PATCH] Nick's scheduler policy v12

From: Nick Piggin (piggin_at_cyberone.com.au)
Date: 09/06/03

  • Next message: Nick Piggin: "Re: [PATCH] Nick's scheduler policy v12" 
    Date:	Sat, 06 Sep 2003 16:38:05 +1000
To: "Martin J. Bligh" <mbligh@aracnet.com>

    Martin J. Bligh wrote:

    >>Yep, as Mike mentioned, renicing X causes it to get bigger
    >>timeslices with the stock scheduler. If you had 2 nice -20 processes,
    >>they would each get a timeslice of 200ms, so you're harming their
    >>latency.
    >>
    >
    >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.
    >

    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.

    When _only_ low priority tasks are running, they'll all get long
    timeslices.

    >
    >>>There may be some more details around this, and I'd love to hear them,
    >>>but I fundmantally believe that explitit fiddling with particular
    >>>processes because we believe they're somehow magic is wrong (and so
    >>>does Linus, from previous discussions).
    >>>
    >>Well it would be nice if someone could find out how to do it, but I
    >>think that if we want X to be able to get 80% CPU when 2 other CPU hogs
    >>are running, you have to renice it.
    >>
    >
    >OK. So you renice it ... then your two cpu jobs exit, and you kick off
    >xmms. Every time you waggle a window, X will steal the cpu back from
    >xmms, and it'll stall, surely? That's what seemed to happen before.
    >I don't see how you can fix anything by doing static priority alterations
    >(eg nice), because the workload changes.
    >
    >I'm probably missing something ... feel free to slap me ;-)
    >

    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.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Nick Piggin: "Re: [PATCH] Nick's scheduler policy v12"

    Relevant Pages

    • Re: [PATCH] Nicks scheduler policy v12
      ... the other a bigger timeslice. ... >>but X to have a 20ms slice and a very high scheduling priority. ... The way I do it is give a small timeslice to high prio tasks, ... it's chewing quite a bit of CPU ... ...
      (Linux-Kernel)
    • Re: [SHED] Questions.
      ... > times / timeslice. ... >> If timeslices did not play a role, then high priority tasks would always ... This happened on Amiga. ... > Yes, like the feedback scheduler... ...
      (Linux-Kernel)
    • [HPADM] RE: Re: HP-UX equivalent for : a) cpulimit b) kill -STOP / -CONT
      ... Renice will change the priority that a process gets a timeslice. ... This assumes 100% CPU and no I/O. ...
      (HP-UX-Admin)
    • Re: [PATCH] Nicks scheduler policy v12
      ... the other a bigger timeslice. ... >>but X to have a 20ms slice and a very high scheduling priority. ... >>xmms is that X is at its highest dynamic priority. ...
      (Linux-Kernel)
    • Re: [PATCH] O12.2int for interactivity
      ... > for the next epoch as they are moved onto the expired queue. ... > every task on the system had its timeslice recomputed in one large ... Ok, so beyond the prioritization based on dynamic priority, it seems ... >>lists, eh? ...
      (Linux-Kernel)