Re: [PATCH] Nick's scheduler policy v12

[Ed Sweetman]

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
> > timeslices.
>
>
> 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 
players.


-
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/