From: Balbir Singh <balbir@in.ibm.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Martin Ohlin <martin.ohlin@control.lth.se>, linux-kernel@vger.kernel.org
Subject: Re: A nice CPU resource controller
Date: Thu, 31 Aug 2006 11:47:06 +0530 [thread overview]
Message-ID: <44F67EE2.5060605@in.ibm.com> (raw)
In-Reply-To: <44F6365A.8010201@bigpond.net.au>
Peter Williams wrote:
>> I do not understand controlling the nice value? Most cpu control the
>> bandwidth/time - are there any advantages to controlling the nice
>> value?
>
> Trying to control CPU allocations purely using time allocations will
> only work well for CPU bound processes. Furthermore, the faster CPUs
> become the more this will be the case.
The resource we are controlling is CPU bandwidth, what other parameters can we
use to control it?. Nice values indirectly control the time a task gets, but
also affects its priority. Even if a task is not CPU bound, we are only
interested in its CPU bandwidth utilization in the CPU resource controller.
>
>> How does this interplay with dynamic priorities that the
>> scheduler currently maintains?
>
> But your implication here is valid. It is better to fiddle with the
> dynamic priorities than with nice as this leaves nice for its primary
> purpose of enabling the sysadmin to effect the allocation of CPU
> resources based on external considerations. Having said that I would
> also opine that the basic mechanism this author uses to fiddle the nice
> values could be applied to the dynamic priorities instead with the key
> difference being that nice can be fiddled from outside the scheduler but
> you really need to be inside the scheduler to fiddle with dynamic
> priorities.
>
The problem with controlling nice values that I see is that nice values do not
necessarily linearly map CPU time. Changing the nice value also changes the
priority, which impacts the order in which tasks are run.
It's my belief that time and priorities are orthogonal. Nice does a good job
of trying to mix the two, but in the case of resource management it might not
be such a good idea.
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
next prev parent reply other threads:[~2006-08-31 6:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 15:14 A nice CPU resource controller Martin Ohlin
2006-08-30 15:41 ` Balbir Singh
2006-08-30 16:13 ` Martin Ohlin
2006-08-31 6:03 ` Balbir Singh
2006-08-31 1:07 ` Peter Williams
2006-08-31 6:17 ` Balbir Singh [this message]
2006-08-31 10:08 ` Peter Williams
2006-08-31 10:44 ` Mike Galbraith
2006-08-31 6:53 ` Mike Galbraith
2006-08-31 5:21 ` Peter Williams
2006-08-31 7:44 ` Mike Galbraith
2006-08-31 7:42 ` Mike Galbraith
2006-08-31 10:35 ` Martin Ohlin
2006-08-31 14:17 ` Mike Galbraith
2006-08-31 16:01 ` Chris Friesen
2006-08-31 19:14 ` Mike Galbraith
2006-08-31 23:52 ` Peter Williams
2006-08-31 10:21 ` Martin Ohlin
2006-08-31 11:13 ` Balbir Singh
2006-08-31 18:25 ` Peter Grandi
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=44F67EE2.5060605@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.ohlin@control.lth.se \
--cc=pwil3058@bigpond.net.au \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox