From: Peter Williams <pwil3058@bigpond.net.au>
To: Mike Galbraith <efault@gmx.de>
Cc: Con Kolivas <kernel@kolivas.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Kingsley Cheung <kingsley@aurema.com>,
Ingo Molnar <mingo@elte.hu>,
Rene Herman <rene.herman@keyaccess.nl>
Subject: Re: [RFC 0/5] sched: Add CPU rate caps
Date: Sat, 27 May 2006 10:16:17 +1000 [thread overview]
Message-ID: <44779A51.5010206@bigpond.net.au> (raw)
In-Reply-To: <1148630661.7589.65.camel@homer>
Mike Galbraith wrote:
> On Fri, 2006-05-26 at 14:20 +1000, Peter Williams wrote:
>> These patches implement CPU usage rate limits for tasks.
>>
>> Although the rlimit mechanism already has a CPU usage limit (RLIMIT_CPU)
>> it is a total usage limit and therefore (to my mind) not very useful.
>> These patches provide an alternative whereby the (recent) average CPU
>> usage rate of a task can be limited to a (per task) specified proportion
>> of a single CPU's capacity.
>
> The killer problem I see with this approach is that it doesn't address
> the divide and conquer problem. If a task is capped, and forks off
> workers, each worker inherits the total cap, effectively extending same.
>
> IMHO, per task resource management is too severely limited in it's
> usefulness, because jobs are what need managing, and they're seldom
> single threaded. In order to use per task limits to manage any given
> job, you have to both know the number of components, and manually
> distribute resources to each component of the job. If a job has a
> dynamic number of components, it becomes impossible to manage.
Doing caps at a process level inside the scheduler is doable but would
involve an extra level of complexity including locking at the process
level to calculate process usage rates. Also the calculation of usage
rates would be more complex than just doing it for tasks and the fact
that there are not separate structures for processes and threads also
complicates the code compared to what is required otherwise (e.g. for
Solaris).
I'm not sure that this extra complexity is warranted when it is possible
to implement caps at the process level from outside the scheduler using
the task level caps provided by this patch. However, to allow the costs
to be properly evaluated, I'll put some effort into a process level
capping mechanism over the next few weeks.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2006-05-27 0:16 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-26 4:20 [RFC 0/5] sched: Add CPU rate caps Peter Williams
2006-05-26 4:20 ` [RFC 1/5] sched: Fix priority inheritence before CPU rate soft caps Peter Williams
2006-05-26 4:20 ` [RFC 2/5] sched: Add " Peter Williams
2006-05-26 10:48 ` Con Kolivas
2006-05-26 11:15 ` Mike Galbraith
2006-05-26 11:17 ` Con Kolivas
2006-05-26 11:30 ` Mike Galbraith
2006-05-26 13:55 ` Peter Williams
2006-05-27 6:31 ` Balbir Singh
2006-05-27 7:03 ` Peter Williams
2006-05-28 0:11 ` Peter Williams
2006-05-28 7:38 ` Balbir Singh
2006-05-28 13:35 ` Peter Williams
2006-05-28 14:42 ` Balbir Singh
2006-05-28 23:27 ` Peter Williams
2006-05-31 13:17 ` Kirill Korotaev
2006-05-31 23:39 ` Peter Williams
2006-06-01 8:09 ` Kirill Korotaev
2006-06-01 23:38 ` Peter Williams
2006-06-02 1:35 ` Peter Williams
2006-05-26 4:20 ` [RFC 3/5] sched: Add CPU rate hard caps Peter Williams
2006-05-26 6:58 ` Kari Hurtta
2006-05-27 1:00 ` Peter Williams
2006-05-26 11:00 ` Con Kolivas
2006-05-26 13:59 ` Peter Williams
2006-05-26 14:12 ` Con Kolivas
2006-05-26 14:23 ` Mike Galbraith
2006-05-27 0:16 ` Peter Williams
2006-05-27 9:28 ` Mike Galbraith
2006-05-28 2:09 ` Peter Williams
2006-05-27 6:48 ` Balbir Singh
2006-05-27 8:44 ` Peter Williams
2006-05-31 13:10 ` Kirill Korotaev
2006-05-31 15:59 ` Balbir Singh
2006-05-31 18:09 ` Mike Galbraith
2006-06-01 7:41 ` Kirill Korotaev
2006-06-01 8:34 ` Balbir Singh
2006-06-01 18:43 ` [ckrm-tech] " Chandra Seetharaman
2006-06-01 23:26 ` Peter Williams
2006-06-02 2:02 ` Chandra Seetharaman
2006-06-02 3:21 ` Peter Williams
2006-06-02 8:32 ` Balbir Singh
2006-06-02 13:30 ` Peter Williams
2006-06-02 18:58 ` Balbir Singh
2006-06-02 23:49 ` Peter Williams
2006-06-03 4:59 ` Balbir Singh
2006-06-02 19:06 ` Chandra Seetharaman
2006-06-03 0:04 ` Peter Williams
2006-06-02 0:36 ` Con Kolivas
2006-06-02 2:03 ` [ckrm-tech] " Chandra Seetharaman
2006-06-02 5:55 ` [ckrm-tech] [RFC 3/5] " Peter Williams
2006-06-02 7:47 ` Kirill Korotaev
2006-06-02 13:34 ` Peter Williams
2006-06-05 22:11 ` Sam Vilain
2006-06-06 8:24 ` Kirill Korotaev
2006-06-06 9:13 ` Con Kolivas
2006-06-06 9:28 ` Kirill Korotaev
2006-06-02 8:46 ` Mike Galbraith
2006-06-02 13:18 ` Peter Williams
2006-06-02 14:47 ` Mike Galbraith
2006-06-03 0:08 ` Peter Williams
2006-06-03 6:02 ` Mike Galbraith
2006-06-03 11:03 ` Peter Williams
2006-06-06 11:26 ` Srivatsa Vaddagiri
2006-06-02 7:34 ` Kirill Korotaev
2006-06-02 21:23 ` Shailabh Nagar
2006-06-01 23:47 ` Sam Vilain
2006-06-01 23:43 ` Peter Williams
2006-05-31 23:28 ` Peter Williams
2006-06-01 7:44 ` Kirill Korotaev
2006-06-01 23:21 ` Peter Williams
2006-05-26 4:21 ` [RFC 4/5] sched: Add procfs interface for CPU rate soft caps Peter Williams
2006-05-26 4:21 ` [RFC 5/5] sched: Add procfs interface for CPU rate hard caps Peter Williams
2006-05-26 8:04 ` [RFC 0/5] sched: Add CPU rate caps Mike Galbraith
2006-05-26 16:11 ` Björn Steinbrink
2006-05-28 22:46 ` Sam Vilain
2006-05-28 23:30 ` Peter Williams
2006-05-29 3:09 ` Sam Vilain
2006-05-29 3:41 ` Peter Williams
2006-05-29 21:16 ` Sam Vilain
2006-05-29 23:12 ` Peter Williams
2006-05-30 2:07 ` Sam Vilain
2006-05-30 2:45 ` Peter Williams
2006-05-30 22:05 ` Sam Vilain
2006-05-30 23:22 ` Peter Williams
2006-05-30 23:25 ` Peter Williams
2006-06-05 23:56 ` Peter Williams
2006-05-27 0:16 ` Peter Williams [this message]
2006-05-26 10:41 ` Con Kolivas
2006-05-27 1:28 ` Peter Williams
2006-05-27 1:42 ` Con Kolivas
2006-05-26 11:09 ` Con Kolivas
2006-05-26 14:00 ` Peter Williams
2006-05-26 11:29 ` Balbir Singh
2006-05-27 1:40 ` Peter Williams
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=44779A51.5010206@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=kingsley@aurema.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rene.herman@keyaccess.nl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.