[lkml]   [2003]   [Sep]   [6]   [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.
    > Right.
    >>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?
    > So it would seem to make sense to boost the prio of a interactive task
    > *without* increasing the size of it's timeslice.
    >>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?
    > M.

    If you dont see why X is super special then why is xmms even a part of
    the discussion? All of this basing scheduling performance on a bloated
    wannabe winamp makes as much sense as gauging car performance using a
    van. If this was a purely scheduling problem, then why do other
    players like alsaplayer and such not suck as bad as xmms when under the
    exact same priority and all? At least use something without a frontend
    so that you can limit the possibility that the programmers did something
    stupid like make decoding dependent on some update to the gui. xmms was
    coded first and foremost to look and work like winamp. Streamlined -
    even low latency performance was not a base goal. And outside of these
    two programs X and some audio player, how are things going to be
    effected? Forget having to renice certain processes, if i have a video
    player that say, outputs using X will the video thread get lowered below
    certain other processes because the audio thread is getting a higher
    dynamic priority and the video thread uses a lot of cpu (maybe i dont
    have hw accel). What about video players that dont use theads, they
    require both a lot of cpu and audio playing performance to stay in sync,
    will it be dropped below the priority of other apps?

    It's early for me so maybe i'm overreacting. I just dont see the logic
    in using a program like xmms to guage audio playback performance since
    it's main goal is to be like winamp, not efficiently playback audio and
    so can be introducing all kinds of performance hits not found in other

    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:10.428 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site