From: Paul Jackson <pj@sgi.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: serue@us.ibm.com, vatsa@in.ibm.com,
ckrm-tech@lists.sourceforge.net, balbir@in.ibm.com,
rohitseth@google.com, haveblue@us.ibm.com, xemul@sw.ru,
dev@sw.ru, containers@lists.osdl.org, devel@openvz.org,
ebiederm@xmission.com, mbligh@google.com, cpw@sgi.com,
menage@google.com, svaidy@linux.vnet.ibm.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
Date: Thu, 7 Jun 2007 12:21:21 -0700 [thread overview]
Message-ID: <20070607122121.24fe6ff4.pj@sgi.com> (raw)
In-Reply-To: <20070607180158.GA936@sergelap.austin.ibm.com>
> For /cpusets/set0/set1 to have cpu 1 exclusively, does /cpusets/set0
> also have to have it exclusively?
Yes.
> If so, then clearly this approach won't work, since if any container has
> exclusive cpus, then every container will have siblings with exclusive
> cpus, and unshare still isn't possible on the system.
Well, if I'm following you, not exactly.
If we have some exclusive flags set, then every top level container
will have exclusive siblings, but further down the hierarchy, some
subtree might be entirely free of any exclusive settings. Then nodes
below the top of that subtree would not have exclusive set, and would
not have any exclusive siblings.
But, overall, yeah, exclusive is no friend of container cloning.
I just wish I had been thinking harder about how container cloning
will impact my life, and the lives of the customers in my cpuset
intensive corner of the world.
There are certainly a whole bunch of people who will never have any
need for exclusive cpusets.
Perhaps (speculating wildly from great ignorance) there are a whole
bunch of people who will never have need for container cloning.
And perhaps, hoping to get lucky here, the set of people who need both
at the same time on the same system is sufficiently close to empty
that we can just tell them tough toenails - you cannot do both at once.
How wide spread will be the use of container cloning, if it proceeds
as envisioned?
The set of people using exclusive cpusets is roughly some subset of
those running multiple, cpuset isolated, non-cooperating jobs on big
iron, usually with the aid of a batch scheduler. Well, that's what
I am aware of anyway. If there are any other friends of exclusive
cpusets lurking here, you might want to speak up, before I sell your
interests down the river.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2007-06-07 19:21 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 13:01 [PATCH 00/10] Containers(V10): Generic Process Containers menage
2007-05-29 13:01 ` [PATCH 01/10] Containers(V10): Basic container framework menage
2007-05-30 7:15 ` Andrew Morton
2007-05-30 7:15 ` Andrew Morton
2007-05-30 14:02 ` Paul Menage
2007-05-30 16:00 ` Andrew Morton
2007-06-13 10:17 ` Dhaval Giani
2007-05-29 13:01 ` [PATCH 02/10] Containers(V10): Example CPU accounting subsystem menage
2007-05-30 7:16 ` Andrew Morton
2007-05-29 13:01 ` [PATCH 03/10] Containers(V10): Add tasks file interface menage
2007-06-07 14:00 ` Cedric Le Goater
2007-06-07 17:12 ` Paul Menage
2007-05-29 13:01 ` [PATCH 04/10] Containers(V10): Add fork/exit hooks menage
2007-05-29 13:01 ` [PATCH 05/10] Containers(V10): Add container_clone() interface menage
2007-05-30 7:16 ` Andrew Morton
2007-05-31 19:56 ` Serge E. Hallyn
2007-05-29 13:01 ` [PATCH 06/10] Containers(V10): Add procfs interface menage
2007-05-29 13:01 ` [PATCH 07/10] Containers(V10): Make cpusets a client of containers menage
2007-05-29 13:01 ` [PATCH 08/10] Containers(V10): Share css_group arrays between tasks with same container memberships menage
2007-05-29 13:01 ` [PATCH 09/10] Containers(V10): Simple debug info subsystem menage
2007-05-29 13:01 ` [PATCH 10/10] Containers(V10): Support for automatic userspace release agents menage
2007-05-30 7:14 ` [PATCH 00/10] Containers(V10): Generic Process Containers Andrew Morton
2007-05-30 7:39 ` William Lee Irwin III
2007-06-28 21:27 ` Paul Menage
2007-06-28 22:13 ` [ckrm-tech] " Srivatsa Vaddagiri
2007-05-30 8:09 ` Balbir Singh
2007-05-30 9:02 ` Pavel Emelianov
2007-05-30 9:02 ` Balbir Singh
2007-05-30 10:48 ` Pavel Emelianov
2007-06-04 19:14 ` Serge E. Hallyn
2007-06-04 19:31 ` Paul Jackson
2007-06-04 20:30 ` Paul Menage
2007-06-04 20:37 ` Paul Jackson
2007-06-04 20:41 ` Serge E. Hallyn
2007-06-04 21:05 ` Paul Jackson
2007-06-06 22:39 ` Serge E. Hallyn
2007-06-06 22:43 ` Paul Jackson
2007-06-07 0:05 ` Serge E. Hallyn
2007-06-07 0:46 ` [ckrm-tech] " Paul Jackson
2007-06-07 18:01 ` Serge E. Hallyn
2007-06-07 19:21 ` Paul Jackson [this message]
2007-06-07 20:17 ` Serge E. Hallyn
2007-06-07 22:01 ` Paul Jackson
2007-06-08 14:32 ` Serge E. Hallyn
2007-06-08 15:55 ` Paul Menage
2007-06-08 16:08 ` Serge E. Hallyn
2007-06-08 16:16 ` Paul Menage
2007-06-08 18:08 ` Serge E. Hallyn
2007-06-08 18:13 ` Paul Menage
2007-06-08 19:42 ` Serge E. Hallyn
2007-06-08 20:05 ` Paul Jackson
2007-06-08 17:37 ` Paul Jackson
2007-06-04 20:32 ` Paul Menage
2007-06-04 20:51 ` Serge E. Hallyn
2007-06-04 20:56 ` Paul Menage
2007-06-04 21:11 ` Serge E. Hallyn
2007-06-04 21:16 ` Paul Jackson
2007-06-04 21:09 ` [ckrm-tech] " 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=20070607122121.24fe6ff4.pj@sgi.com \
--to=pj@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=containers@lists.osdl.org \
--cc=cpw@sgi.com \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=menage@google.com \
--cc=rohitseth@google.com \
--cc=serue@us.ibm.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.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