lkml.org 
[lkml]   [2003]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.0-test6


Ed Sweetman wrote:

> Nick Piggin wrote:
>
>>
>>
>> Rob Landley wrote:
>>
>>> On Sunday 28 September 2003 02:03, Con Kolivas wrote:
>>>
>>>> On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
>>>>
>>>>> from Andrew Morton. Most notably perhaps Con's scheduler changes that
>>>>> have been discussed extensively and made it into the -mm tree for
>>>>> testing.
>>>>>
>>>> For those who are trying this for the first time, please note that the
>>>> 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).
>>>>
>>>
>>> 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.
>>>
>>
>> AFAIK, Con's scheduler doesn't change the nice implementation at all.
>> 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.
>>
>
> there are 40 positions between -20 and 19, that doesn't equal 5%
> steps. They


No, but the maximum timeslice (sole metric changed by nice) is 200, the
min is 10 (5%). And between them, timeslices are calculated linearly.

> 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


No, but it should get 2000% of what a nice +19 process will get in the
same system (regardless of what else is running).

> 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


They do.

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


I don't know exactly what nice is supposed to do other than "raise
priority", but its fairly well accepted that it should increase the
process' % cpu time (vs others) without completely starving everyone.

It is probably a justified criticism that 5% is too much for a +19 task
to get vs a -20 task, but it has to get something.

-
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:49    [W:0.140 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site