Home » Mailing lists » Devel » [PATCH 00/10] Containers(V10): Generic Process Containers
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers [message #13915 is a reply to message #13914] |
Thu, 07 June 2007 20:17 |
serue
Messages: 750 Registered: February 2006
|
Senior Member |
|
|
Quoting Paul Jackson (pj@sgi.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?
It's not just container cloning, but all namespace unsharing. So uses
include (1) providing 'polyinstantiated directory' functionality, i.e.
private per-user /tmp's or per-security-level /tmp and /home's. (2) any
virtual server usage (3) hpc checkpoint/restart users.
> 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.
Unfortunately I would imagine these users to be very intereseted in
providing checkpoint/restart/migrate functionality.
> 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
Can you explain to me, though, why it should be that if /cpusets/set0
has access to cpus 0-8, and /cpusets/set0/set1 has exclusive access to
cpus 0-2, and /cpusets/set0/set2 has exclusive access to cpus 3-4,
why i a process in /cpusets/set0 creates /cpusets/set0/set3 through
container_clone, it would be unsafe to have it automatically get cpus 5-8?
Surely if the admin wants to give cpus 5-6 exclusively to /cpusets/set0/set4
later, those cpus can just be taken away from set3?
thanks,
-serge
|
|
|
|
|
[PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
[PATCH 09/10] Containers(V10): Simple debug info subsystem
|
|
|
[PATCH 07/10] Containers(V10): Make cpusets a client of containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Mon, 04 June 2007 20:41
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Wed, 06 June 2007 22:39
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Thu, 07 June 2007 00:05
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Thu, 07 June 2007 18:01
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Thu, 07 June 2007 20:17
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
By: serge on Fri, 08 June 2007 14:32
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
By: serge on Fri, 08 June 2007 16:08
|
|
|
Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Mon, 04 June 2007 19:14
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Mon, 04 June 2007 20:51
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
By: serue on Mon, 04 June 2007 21:11
|
|
|
Re: [PATCH 00/10] Containers(V10): Generic Process Containers
|
Goto Forum:
Current Time: Wed Oct 16 04:48:37 GMT 2024
Total time taken to generate the page: 0.04973 seconds
|