mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®