[Devel] [PATCH] cgroup/cpuset: emulate cgroup in container

Stanislav Kinsburskiy skinsbursky at virtuozzo.com
Wed Dec 13 16:24:17 MSK 2017


Hi Pavel, please, see my comments/question below

13.12.2017 13:43, Pavel Tikhomirov пишет:
> Personally I don't like these as we still have no unswer to "If cpusets are optional for docker, why k8s can't work without them?" it seem there is not enough explanation in VZAP-31.
> 

Well... I have to admit that I don't like it either.
I (frankly) don't like the whole idea of putting kuber into container.
And the reason is so simple: CT is a cheating technique. Those, who like "Russian dolls" should use VMs with nested virtualization.
But the truth is that we do care about our customers (not sure why, since they pay us less and less).
And because of this we've put so much various sh*t into our kernel already, that I got tired to trow it away on each major rebase a long time ago.
But this all is lyrics.
There is a task - and that's the fix.

> We also need to revert the patch below to show cpuset in CT:
> commit 5160bd34c9bd ("ve/proc/cpuset: do not show cpuset in CT")
> 

Sure! It's mentioned in the patch description.

> It seem I can still attach a process to a nested cgroup in CT with these patch:
> 
> CT-6ecd9be1 /# cat /proc/cgroups | grep cpuset
> cpuset    16    1    1
> CT-6ecd9be1 /# ls /sys/fs/cgroup/cpuset/cpuset.cpus
> /sys/fs/cgroup/cpuset/cpuset.cpus
> CT-6ecd9be1 /# mkdir /sys/fs/cgroup/cpuset/test
> CT-6ecd9be1 /# sleep 1000 &
> [1] 678
> CT-6ecd9be1 /# echo  678 > /sys/fs/cgroup/cpuset/test/tasks
> CT-6ecd9be1 /# cat /sys/fs/cgroup/cpuset/test/tasks
> 678
> 

Isn't it wonderful? :)
Poor me, I have to admit, that I didn't know, that this task will be even visible in the nest cgroup... :(
I thought, that emulation would be less effective.

Nevertheless, if you have some better way to solve the issue, please, share.

> On 12/13/2017 01:37 PM, Stanislav Kinsburskiy wrote:
>> Any changes to this cgroup are skipped in container, but success code is
>> returned.
>> The idea is to fool Docker/Kubernetes.
>>
>> https://jira.sw.ru/browse/PSBM-58423
>>
>> This patch obsoletes "ve/proc/cpuset: do not show cpuset in CT"
>>
>> Signed-off-by: Stanislav Kinsburskiy <skinsbursky at virtuozzo.com>
>> ---
>>   kernel/cpuset.c |    9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
>> index 26d88eb..dfac505 100644
>> --- a/kernel/cpuset.c
>> +++ b/kernel/cpuset.c
>> @@ -1441,6 +1441,9 @@ static int cpuset_can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
>>       struct task_struct *task;
>>       int ret;
>>   +    if (!ve_is_super(get_exec_env()))
>> +        return 0;
>> +
>>       mutex_lock(&cpuset_mutex);
>>         ret = -ENOSPC;
>> @@ -1470,6 +1473,9 @@ static int cpuset_can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
>>   static void cpuset_cancel_attach(struct cgroup *cgrp,
>>                    struct cgroup_taskset *tset)
>>   {
>> +    if (!ve_is_super(get_exec_env()))
>> +        return;
>> +
>>       mutex_lock(&cpuset_mutex);
>>       cgroup_cs(cgrp)->attach_in_progress--;
>>       mutex_unlock(&cpuset_mutex);
>> @@ -1494,6 +1500,9 @@ static void cpuset_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
>>       struct cpuset *cs = cgroup_cs(cgrp);
>>       struct cpuset *oldcs = cgroup_cs(oldcgrp);
>>   +    if (!ve_is_super(get_exec_env()))
>> +        return;
>> +
>>       mutex_lock(&cpuset_mutex);
>>         /* prepare for attach */
>>
> 


More information about the Devel mailing list