LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Arnd Bergmann" <arnd@arndb.de>, "Christoph Hellwig" <hch@lst.de>,
	cbe-oss-dev@ozlabs.org, "Jeremy Kerr" <jk@ozlabs.org>,
	linux-kernel@vger.kernel.org
Subject: Re: SCHED_IDLE documentation
Date: Wed, 5 Mar 2008 16:02:04 +0100	[thread overview]
Message-ID: <cfd18e0f0803050702w57d22f5h2646a59be3337d1d@mail.gmail.com> (raw)
In-Reply-To: <cfd18e0f0803030642m62cec927p80f1250fbe98afc6@mail.gmail.com>

On Mon, Mar 3, 2008 at 3:42 PM, Michael Kerrisk
<mtk.manpages@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

      reply	other threads:[~2008-03-05 15:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1203376368.275756.252634247263.1.gpush@pokey>
     [not found] ` <200803030612.28039.arnd@arndb.de>
     [not found]   ` <20080303051719.GA26102@lst.de>
2008-03-03  6:21     ` Arnd Bergmann
2008-03-03  7:33       ` Ingo Molnar
2008-03-03  8:40         ` Michael Kerrisk
2008-03-03  9:24           ` Ingo Molnar
2008-03-03  9:31             ` Arnd Bergmann
2008-03-03 10:03               ` Michael Kerrisk
2008-03-03 10:04               ` Ingo Molnar
2008-03-03 10:12                 ` Michael Kerrisk
2008-03-03 10:07             ` Michael Kerrisk
2008-03-03 10:17               ` Ingo Molnar
2008-03-03 10:20                 ` Michael Kerrisk
2008-03-03 12:31             ` Michael Kerrisk
2008-03-03 12:52               ` Ingo Molnar
2008-03-03 14:06                 ` Michael Kerrisk
2008-03-04 11:11                   ` Peter Zijlstra
2008-03-05 15:19                     ` Michael Kerrisk
2008-03-03 14:42                 ` Michael Kerrisk
2008-03-05 15:02                   ` Michael Kerrisk [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cfd18e0f0803050702w57d22f5h2646a59be3337d1d@mail.gmail.com \
    --to=mtk.manpages@googlemail.com \
    --cc=arnd@arndb.de \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=hch@lst.de \
    --cc=jk@ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --subject='Re: SCHED_IDLE documentation' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).