LKML Archive on
help / color / mirror / Atom feed
From: "Paul Menage" <>
Cc: "Dhaval Giani" <>,
	lkml <>,,
	"Balbir Singh" <>,
	"Peter Zijlstra" <>,
	"Srivatsa Vaddagiri" <>,
	"Sudhir Kumar" <>
Subject: Re: [RFC] libcg: design and plans
Date: Wed, 5 Mar 2008 10:55:02 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Mar 5, 2008 at 6:24 AM, Balbir Singh <> wrote:
> Paul Menage wrote:
>  > On Wed, Mar 5, 2008 at 3:07 AM, Dhaval Giani <> wrote:
>  >>  OK. Hmm, I've not really thought about it. At first thought, it should
>  >>  not be very difficult. Only thing I am not sure is the arbitrary
>  >>  grouping of the groups (ok, a bit confusing).
>  >
>  > I suspect that the main form of composite grouping is going to be
>  > between parents and children. E.g. you might want to say things like:
>  >
>  > create_group(A, memory=1G, cpu=100)
>  > create_group(B, parent=A, memory=inherit, cpu=20)
>  > create_group(C, parent=A, memory=inherit, cpu=30)
>  >
>  > i.e. both B and C inherit/share their memory limit from their parent,
>  > but have their own CPU groups (child groups of their parent?)
>  >
>  No, we don't plan on doing that. What we plan on doing is
>  1. Specify the mount point for each controller
>  2. In the create group API, specify the name of the group and the various
>  parameters.
>  If for example CPU is mounted at /cpu and Memory at /mem
>  Then a specification for creation of group A would be of the form
>  create_group(A, cpu=100, memory=100M)
>  Then,
>  /cpu/A has shares set to 100 and /mem/A has memory.limit set to 100M
>  If you want to create subgroups under A, you specify
>  create_group(A/B, memory=200M, cpu=50)
>  That would create /cpu/A/B and /mem/A/B
>  Please note that memory and CPU hierarchy needs work in the kernel. The shares
>  and hierarchy support is pending. We need to make the res_counters
>  infrastructure aware of hierarchies.

I think there are two different kinds of sharing going on here:

- A and B each have individual limits, and you additionally want their
total usage to be capped by some parent limit. E.g. A and B each have
a 100MB memory limit, and you want their total combined usage to not
exceed 150MB. This kind of sharing has to be handled by the resource
counter abstraction

- you want A and B to be treated identically for the purposes of some
particular resource, e.g. you want a single CFS group to which all
threads in A and B are equal members, or a single memory cgroup for
all allocations by A or B, or the same device control table for A and
B (but you want A and B to be treated separately for some other
resource type). This can be handled in userspace in the way I outlined
above, and it would be good if libcg could handle the setup required
for this. It could also be done in the kernel with something like the
parent/child subsystem group inheritance that I also mentioned above,
if there was demand. But if so it should be a property of cgroups
rather than any individual resource controller, since it's a feature
that could be useful for all cgroups.


  reply	other threads:[~2008-03-05 18:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-04 15:23 Dhaval Giani
2008-03-04 17:15 ` Xpl++
2008-03-05  4:48   ` Balbir Singh
2008-03-05  5:26   ` Dhaval Giani
2008-03-05 11:56     ` Xpl++
2008-03-05 15:53       ` Dhaval Giani
2008-03-05 19:36         ` Xpl++
2008-03-04 18:05 ` Dave Hansen
2008-03-05  6:15 ` Paul Menage
2008-03-05  7:17   ` [Devel] " Denis V. Lunev
2008-03-05 11:48     ` Balbir Singh
2008-03-05 10:33   ` Dhaval Giani
2008-03-05 10:41     ` Paul Menage
2008-03-05 11:07       ` Dhaval Giani
2008-03-05 11:51         ` Paul Menage
2008-03-05 14:24           ` Balbir Singh
2008-03-05 18:55             ` Paul Menage [this message]
2008-03-20 22:04 ` Rik van Riel

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC] libcg: design and plans' \

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