All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: balbir@in.ibm.com
Cc: Peter Williams <peterw@aurema.com>,
	sekharan@us.ibm.com, Andrew Morton <akpm@osdl.org>,
	dev@openvz.org, Srivatsa <vatsa@in.ibm.com>,
	ckrm-tech@lists.sourceforge.net,
	Balbir Singh <bsingharora@gmail.com>,
	Mike Galbraith <efault@gmx.de>, Con Kolivas <kernel@kolivas.org>,
	Sam Vilain <sam@vilain.net>,
	Kingsley Cheung <kingsley@aurema.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@elte.hu>,
	Rene Herman <rene.herman@keyaccess.nl>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps
Date: Fri, 02 Jun 2006 23:30:05 +1000	[thread overview]
Message-ID: <44803D5D.20303@bigpond.net.au> (raw)
In-Reply-To: <447FF7BB.9000104@in.ibm.com>

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).

> 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.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-06-02 13:30 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 [this message]
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
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=44803D5D.20303@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=balbir@in.ibm.com \
    --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=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 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.