From: "Paul Menage" <menage@google.com>
To: vatsa@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, a.p.zijlstra@chello.nl,
"Ingo Molnar" <mingo@elte.hu>,
containers@lists.osdl.org, dhaval@linux.vnet.ibm.com,
"Balbir Singh" <balbir@in.ibm.com>,
pj@sgi.com
Subject: Re: [RFC] Default child of a cgroup
Date: Thu, 31 Jan 2008 18:39:56 -0800 [thread overview]
Message-ID: <6599ad830801311839x33cf2ebco9f501571fc129b11@mail.gmail.com> (raw)
In-Reply-To: <20080131024049.GA9544@linux.vnet.ibm.com>
On Jan 30, 2008 6:40 PM, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote:
>
> Here are some questions that arise in this picture:
>
> 1. What is the relationship of the task-group in A/tasks with the
> task-group in A/a1/tasks? In otherwords do they form siblings
> of the same parent A?
I'd argue the same as Balbir - tasks in A/tasks are are children of A
and are siblings of a1, a2, etc.
>
> 2. Somewhat related to the above question, how much resource should the
> task-group A/a1/tasks get in relation to A/tasks? Is it 1/2 of parent
> A's share or 1/(1 + N) of parent A's share (where N = number of tasks
> in A/tasks)?
Each process in A should have a scheduler weight that's derived from
its static_prio field. Similarly each subgroup of A will have a
scheduler weight that's determined by its cpu.shares value. So the cpu
share of any child (be it a task or a subgroup) would be equal to its
own weight divided by the sum of weights of all children.
So yes, if a task in A forks lots of children, those children could
end up getting a disproportionate amount of the CPU compared to tasks
in A/a1 - but that's the same as the situation without cgroups. If you
want to control cpu usage between different sets of processes in A,
they should be in sibling cgroups, not directly in A.
Is there a restriction in CFS that stops a given group from
simultaneously holding tasks and sub-groups? If so, couldn't we change
CFS to make it possible rather than enforcing awkward restructions on
cgroups?
If we really can't change CFS in that way, then an alternative would
be similar to Peter's suggestion - make cpu_cgroup_can_attach() fail
if the cgroup has children, and make cpu_cgroup_create() fail if the
cgroup has any tasks - that way you limit the restriction to just the
hierarchy that has CFS attached to it, rather than generically for all
cgroups
BTW, I noticed this code in cpu_cgroup_create():
/* we support only 1-level deep hierarchical scheduler atm */
if (cgrp->parent->parent)
return ERR_PTR(-EINVAL);
Is anyone working on allowing more levels?
Paul
next prev parent reply other threads:[~2008-02-01 2:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-31 2:40 Srivatsa Vaddagiri
2008-01-31 17:44 ` Serge E. Hallyn
2008-01-31 18:09 ` Balbir Singh
2008-01-31 20:37 ` Peter Zijlstra
2008-02-01 4:16 ` Dhaval Giani
2008-02-01 3:53 ` Dhaval Giani
2008-01-31 21:13 ` Vivek Goyal
2008-02-01 2:39 ` Paul Menage [this message]
2008-02-01 3:32 ` Balbir Singh
2008-02-01 3:40 ` Dhaval Giani
2008-02-01 7:58 ` Peter Zijlstra
2008-02-01 15:35 ` Paul Menage
2008-02-01 8:19 ` Srivatsa Vaddagiri
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=6599ad830801311839x33cf2ebco9f501571fc129b11@mail.gmail.com \
--to=menage@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=balbir@in.ibm.com \
--cc=containers@lists.osdl.org \
--cc=dhaval@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=vatsa@linux.vnet.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
all inboxes | Powered by JetHome®