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

Tejun Heo tj at kernel.org
Mon Dec 17 23:48:16 UTC 2012


Hello,

On Mon, Dec 17, 2012 at 02:43:26PM +0800, 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.

So, I'm *highly* unlikely to accept any patches which try to add
namespace support directly to cgroup in any form unless someone can
definitively show me this can't be done using FUSE or other userland
solutions.

cgroupfs is going to be an interface to expose the resource control
facilities of the kernel and that's the extent the interface will be
capable of.  It in itself won't support delegation of resource
policies to names spaces or unprivieged users.

Although I don't have anything concrete yet, the tentative plan is to
have something in userland which can integrate with the base system so
that userland has an unified and controlled way to interact with
cgroup which can be easily integrated with the rest of the base system
and kernel has at least some level of interface isolation.  Basically,
something like libudev or libsysfs.

So, if people want to allow NSes control its subtree of cgroups, I
really want something in the userland which sits between the NSes and
actual cgroup, and I bet things would actually be much better that
way.  cgroupfs seems to allow it but you can't really delegate
management of subtree easily.  Controllers would collapse with
increasing level of nesting, root cgroups have different knobs or
different interpretations of the same knobs, and siblings interact
with each other, and I don't think making cgroupfs interface generic
enough so that it can be used for all that is desirable or a
worthwhile effort.

Thanks.

-- 
tejun


More information about the Containers mailing list