Re: [RFC PATCH 0/9] Add container support for cgroup

On 12/17/2012 10:43 AM, Gao feng wrote:

Right now,if we mount cgroup in the container,we will get
host's cgroup informations and even we can change host's
cgroup in container.

So the resource controller of the container will lose
effectiveness.

This patchset try to add contianer support for cgroup.
the main idea is allocateing cgroup super-block for each
cgroup mounted in different pid namespace.

The top cgroup of container will share css with host.
When the cgroup being mounted in contianer,the tasks in
this container will be attached to this new mounted
hierarchy's top cgroup, And when unmounting cgroup in
container,these tasks will be attached back to host's cgroup.

Since the container can change the shared css through it's
cgroup subsystem files. patch 7/8 disable the write permission
of container's top cgroup files. In my TODO list, container
will have it's own css, this problem will disappear.


This patchset is sent as RFC,any comments are welcome.
Maybe this isn't the best solution, if you have better
solution,Please let me know.

Question 1:

Any particular reason to have picked the pid namespace?

Maybe it is the right thing, since we are basically dealing with
grouping of tasks. OTOH, what you are doing sounds very much like
a private mount, indicating that the mount namespace should be used.
This needs to be well justified.

Also, "container support" can really mean a lot of things. I am still
trying, while reading your patches, to figure out what exactly do you
want to achieve. What it seems so far is that you want an unprivileged
process living inside a namespace to manipulate the cgroup hierarchy and
have its own copy of the cgroup tree, laid as it pleases. You also want
to be able to write PIDs as seen by the containing namespace, and to
have it somehow translated. Am I right?

For future submissions, could you make this clearer?