[Cbe-oss-dev] SCHED_IDLE documentation

[Michael Kerrisk]

On Mon, Mar 3, 2008 at 3:42 PM, Michael Kerrisk
<mtk.manpages at googlemail.com> wrote:
> Ingo,
>
>  One more thought while we're in this thread.  In my recent tests I
>  notice that the magnitude of the effect of nice values has changed
>  quite a lot in recent times.  For example, back in 2.6.18, two CPU
>  intensive processes would get the following shares of the CPU over 100
>  seconds of run time (here, three different examples of nice value
>  settings):
>
>  A nice  B nice  %A      %B
>  -20     -10     58.3    41.7
>  -20       0     89.2    10.8
>  -20     +19     99.7     0.3
>
>  In 2.6.25-rc2, we have:
>
>  A nice  B nice  %A      %B
>  -20     -10      90.5   9.5
>  -20       0      99.0   1.0
>  -20     +19     100.0   0.0
>
>  While I realise that nice values are not intended to guarantee any
>  particular degree of access to the CPU, these wide variations in the
>  effect of the nice value are surprising.  (For the 2.6.25-rc2 -20/+19
>  case, my test shows the low priority process is getting 0.000% of the
>  CPU -- i.e., < one thousandth of a percent.  In other words it is in
>  effect being totally starved of the CPU.)  Any comments?

Off list, Ingo pointed me at
Documentation/scheduler/sched-nice-design.txt which explains the
changes that took effect for nice values in 2.6.32.  I've added a
reference to that doc to the getpriority.2 page, and also added the
following text to NOTES on that page:

       The degree to which their relative nice value affects the
       scheduling  of processes varies across Unix systems, and,
       on Linux, across kernel versions.  Starting  with  kernel
       2.6.23,  Linux  adopted an algorithm that causes relative
       differences in  nice  values  to  have  a  much  stronger
       effect.   This causes very low nice values (+19) to truly
       provide little CPU to a process  whenever  there  is  any
       other  higher priority load on the system, and makes high
       nice values (-20) deliver most of the CPU to applications
       that require it (e.g., some audio applications).

I also tweaked my test program to deliver slightly more accurate info.
 With two CPU bound SCHED_OTHER processes, one at nice -20, the other
at nice+19, I found that the latter process is not _completely_
starved of the CPU: it gets about 0.006% of the CPU during a 5-minute
period..

Cheers,

Michael

-- 
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug?  Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html