On Mon, Sep 29, 2003 at 12:55:12PM -0400, Ed Sweetman wrote:
Nick Piggin wrote:
there are 40 positions between -20 and 19, that doesn't equal 5% steps. They don't even refer to % of cpu. If i nice a process to -20 it doesn't get a given percentage of cpu just because it's -20. I may have other processes at -20 as well. If you nice something to -20 and it is actually using that cpu then things that are +19 shouldn't run and wont run. If I nice -20 vmstat 1, it's not going to starve xmms (or any better audio player). -20 means starve all and it should do that when it actually makes use of the resources.
Rob Landley wrote:
On Sunday 28 September 2003 02:03, Con Kolivas wrote:AFAIK, Con's scheduler doesn't change the nice implementation at all.
On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:I.E. with your new scheduler, priority levels actually have enough of an effect now that things that aren't reniced can be noticeably starved by things that are.
from Andrew Morton. Most notably perhaps Con's scheduler changes that
have been discussed extensively and made it into the -mm tree forFor those who are trying this for the first time, please note that the
testing.
scheduler has been tuned to tell the difference between tasks of the _same_
nice level. This means do NOT renice X or it will make audio skip unless
you also renice your audio application by the same amount. Lots of
distributions have done this for the old 2.4 scheduler which could not
treat equal "nice" levels as differently as the new scheduler does and 2.6
shouldn't need special treatment.
So for testing note the following points:
Make sure X is NOT reniced to -10 as many distributions are doing.
Some shells spawn processes at nice +5 by default and this will make audio
apps suffer.
Make sure your hard disk, graphics card and audio card are performing at
equal standard to your 2.4 kernel (ie dma is working, graphics is fully
accelerated etc).
Possibly some of his changes amplify its problems, or, more likely they
remove most other scheduler problems leaving this one noticable.
If X is running at -20, and xmms at +19, xmms is supposed to still get
5% of the CPU. Should be enough to run fine. Unfortunately this is
achieved by giving X very large timeslices, so xmms's scheduling latency
becomes large. The interactivity bonuses don't help, either.
Why not run xmms with SCHED_RR or SCHED_FIFO?