lkml.org 
[lkml]   [2003]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
>>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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.067 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site