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

[Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>]

Hello Tejun

On 2012/12/18 07:48, Tejun Heo wrote:
> 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.


As your advice,the container's interface will be changed in container.
Container will not be able to enable cgroup by the command:
"mount -t cgroup -o xxx xxx /path".

Though something like libudev or libsysfs can afford the interface for
container to get and set cgroups.But the interface provided by cgroupfs
will lose effectiveness in container.


> 
> 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.
> 

I recognize it's not easy,BUT I just want the usage of the OS which
running in container as same as the host.

Thanks.