Re: [ckrm-tech] [PATCH 00/10] Containers(V10): Generic Process Containers

[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?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/