From: "Paul Menage" <menage@google.com>
To: vatsa@in.ibm.com
Cc: xemul@sw.ru, dev@sw.ru, pj@sgi.com, sam@vilain.net,
ebiederm@xmission.com, winget@google.com, serue@us.ibm.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
ckrm-tech@lists.sourceforge.net, containers@lists.osdl.org
Subject: Re: Summary of resource management discussion
Date: Thu, 15 Mar 2007 04:24:37 -0700 [thread overview]
Message-ID: <6599ad830703150424t3478cd55mf9d2699f3669c9f0@mail.gmail.com> (raw)
In-Reply-To: <20070312124226.GD17151@in.ibm.com>
On 3/12/07, Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:
> - (subjective!) If there is a existing grouping mechanism already (say
> tsk->nsproxy[->pid_ns]) over which res control needs to be applied,
> then the new grouping mechanism can be considered redundant (it can
> eat up unnecessary space in task_struct)
If there really was a grouping that was always guaranteed to match the
way you wanted to group tasks for e.g. resource control, then yes, it
would be great to use it. But I don't see an obvious candidate. The
pid namespace is not it, IMO. Resource control (and other kinds of
task grouping behaviour) shouldn't require virtualization.
>
> a. Paul Menage's patches:
>
> (tsk->containers->container[cpu_ctlr.subsys_id] - X)->cpu_limit
Additionally, if we allow mature container subsystems to have an id
declared in a global enum, then we can make the cpu_ctlr.subsys_id
into a constant.
>
> b. rcfs
> tsk->nsproxy->ctlr_data[cpu_ctlr.subsys_id]->cpu_limit
So what's the '-X' that you're referring to
> 3. How are cpusets related to vserver/containers?
>
> Should it be possible to, lets say, create exclusive cpusets and
> attach containers to different cpusets?
Sounds reasonable.
>
> 6. As tasks move around namespaces/resource-classes, their
> tsk->nsproxy/containers object will change. Do we simple create
> a new nsproxy/containers object or optimize storage by searching
> for one which matches the task's new requirements?
I think the latter.
>
> - If we don't support hierarchy in res controllers today
> but were to add that support later, then
> user-interface shouldn't change. That's why
> designining -atleast- the user interface to support
> hierarchy may make sense
Right - having support for a hierarchy in the API doesn't mean that
individual controllers have to support being in a hierarchy.
Paul
next prev parent reply other threads:[~2007-03-15 11:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-12 12:42 Summary of resource management discussion Srivatsa Vaddagiri
2007-03-13 16:24 ` Herbert Poetzl
2007-03-13 17:58 ` Srivatsa Vaddagiri
2007-03-13 23:50 ` Herbert Poetzl
2007-03-15 11:24 ` Paul Menage [this message]
2007-03-15 17:04 ` Srivatsa Vaddagiri
2007-03-15 19:12 ` Paul Menage
2007-03-16 1:40 ` Srivatsa Vaddagiri
2007-03-16 20:03 ` Eric W. Biederman
2007-03-16 14:26 ` Herbert Poetzl
2007-03-16 14:19 ` Herbert Poetzl
2007-03-16 14:57 ` Srivatsa Vaddagiri
2007-03-16 21:23 ` Paul Jackson
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=6599ad830703150424t3478cd55mf9d2699f3669c9f0@mail.gmail.com \
--to=menage@google.com \
--cc=akpm@linux-foundation.org \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=containers@lists.osdl.org \
--cc=dev@sw.ru \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=sam@vilain.net \
--cc=serue@us.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=winget@google.com \
--cc=xemul@sw.ru \
/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;
as well as URLs for NNTP newsgroup(s).