From: Balbir Singh <balbir@in.ibm.com>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Andrew Morton <akpm@osdl.org>,
dev@openvz.org, Srivatsa <vatsa@in.ibm.com>,
sekharan@us.ibm.com, ckrm-tech@lists.sourceforge.net,
Balbir Singh <bsingharora@gmail.com>,
Mike Galbraith <efault@gmx.de>, Sam Vilain <sam@vilain.net>,
Con Kolivas <kernel@kolivas.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Kingsley Cheung <kingsley@aurema.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>, Peter Williams <peterw@aurema.com>,
Rene Herman <rene.herman@keyaccess.nl>
Subject: Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps
Date: Sat, 03 Jun 2006 00:28:26 +0530 [thread overview]
Message-ID: <44808A52.9040100@in.ibm.com> (raw)
In-Reply-To: <44803D5D.20303@bigpond.net.au>
Peter Williams wrote:
> Balbir Singh wrote:
>
>>Peter Williams wrote:
>><snip>
>>
>>>>>But you don't need something as complex as CKRM either. This capping
>>>>
>>>>All CKRM^W Resource Groups does is to group unrelated/related tasks to a
>>>>group and apply resource limits.
>>>>
>>>>
>>>>>functionality coupled with (the lamented) PAGG patches (should have
>>>>>been called TAGG for "task aggregation" instead of PAGG for "process
>>>>>aggregation") would allow you to implement a kernel module that
>>>>>could apply caps to arbitrary groups of tasks.
>>>>
>>>>I do not follow how PAGG + this cap feature can be used to put cap of
>>>>related/unrelated tasks. Can you provide little more explanation,
>>>>please.
>>>
>>>
>>>I would have thought it was fairly obvious. PAGG supplies the task
>>>aggregation mechanism, these patches provide per task caps and all
>>>that's needed is the code that marries the two.
>>>
>>
>>The problem is that with per-task caps, if I have a resource group A
>>and I want to limit it to 10%, I need to limit each task in resource
>>group A to 10% (which makes resource groups not so useful). Is my
>>understanding correct?
>
>
> Well the general idea is correct but your maths is wrong. You'd have to
> give each of them a cap somewhere between 10% and 10% divided by the
> number of tasks in group A. Exactly where in that range would vary
> depending on the CPU demand of each task and would need to be adjusted
> dynamically (unless they were very boring tasks whose demands were
> constant over time).
>
Hmm.. I thought my math was reasonable (but there is always so much to learn)
>From your formula, if I have 1 task in group A, I need to provide it with
a cap of b/w 10 to 11%. For two tasks, I need to give them b/w 10 to 10.5%.
If I have a hundred, it needs to be b/w 10% and 10.01%
>
>>Is there a way to distribute the group limit
>>across tasks in the resource group?
>
>
> Not as part of this patch but it could be done from outside the
> scheduler either in the kernel or in user space.
>
>
>>>>Also, i do not think it can provide guarantees to that group of tasks.
>>>>can it ?
>>>
>>>
>>>It could do that by manipulating nice which is already available in
>>>the kernel.
>>>
>>>I.e. these patches plus improved statistics (which are coming, I hope)
>>>together with the existing policy controls provide all that is
>>>necessary to do comprehensive CPU resource control. If there is an
>>>efficient way to get the statistics out to user space (also coming, I
>>>hope) this control could be exercised from user space.
>>
>>Could you please provide me with a link to the new improved statistics.
>
>
> No. Read LKML and you'll know as much as I do.
>
>
>>What do the new statistics contain - any heads up on them?
>
>
> There're several contenders (including some from IBM) that periodically
> post patches to LKML. That's where I'm aware of them from. As I say,
> I'm hoping that they get together and come up with something generally
> useful (as opposed to just meeting each contenders needs). I may be
> being overly optimistic but you never know.
Yes, thats the whole point of the discussion and everybody is free to
participate.
>
> Peter
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
next prev parent reply other threads:[~2006-06-02 19:03 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 [this message]
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
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=44808A52.9040100@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=akpm@osdl.org \
--cc=bsingharora@gmail.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dev@openvz.org \
--cc=ebiederm@xmission.com \
--cc=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=kingsley@aurema.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterw@aurema.com \
--cc=pwil3058@bigpond.net.au \
--cc=rene.herman@keyaccess.nl \
--cc=sam@vilain.net \
--cc=sekharan@us.ibm.com \
--cc=vatsa@in.ibm.com \
/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
Powered by JetHome