LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul Menage" <menage@google.com>
To: balbir@linux.vnet.ibm.com
Cc: "Dhaval Giani" <dhaval@linux.vnet.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
containers@lists.linux-foundation.org,
"Balbir Singh" <balbir@in.ibm.com>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Srivatsa Vaddagiri" <vatsa@linux.vnet.ibm.com>,
"Sudhir Kumar" <skumar@linux.vnet.ibm.com>
Subject: Re: [RFC] libcg: design and plans
Date: Wed, 5 Mar 2008 10:55:02 -0800 [thread overview]
Message-ID: <6599ad830803051055r56045dffvbb04a50bc903e0dc@mail.gmail.com> (raw)
In-Reply-To: <47CEAD38.3080501@linux.vnet.ibm.com>
On Wed, Mar 5, 2008 at 6:24 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> Paul Menage wrote:
> > On Wed, Mar 5, 2008 at 3:07 AM, Dhaval Giani <dhaval@linux.vnet.ibm.com> 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.
Paul
next prev parent 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:
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=6599ad830803051055r56045dffvbb04a50bc903e0dc@mail.gmail.com \
--to=menage@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=balbir@in.ibm.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=dhaval@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=skumar@linux.vnet.ibm.com \
--cc=vatsa@linux.vnet.ibm.com \
--subject='Re: [RFC] libcg: design and plans' \
/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
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).