Question about disallowing rename(2) in cgroup v2

Question about disallowing rename(2) in cgroup v2

[taoyi.ty]

hi all,

I found that rename(2) can be used in cgroup v1 but is disallowed in 
cgroup v2, what's the reason for this design?

rename(2) is critical when managing a cgroup pool in userspace, which 
uses rename to reuse cgroup rather than mkdir to create a new one，this 
can improve the performance of container concurrent startup, because 
renaming cgroup is much more lightweight compared with creating cgroup.

For new features in cgroup v2, I switch to cgroup v2 and meet this 
problem, I think renaming cgroup in v2 is similar to v1 and realizing it 
is not a hard problem, so I send this mail to learn the initial design.

Thanks,
-escape

Re: Question about disallowing rename(2) in cgroup v2

[Michal Koutný]

Hi Escape.

On Tue, Jun 28, 2022 at 09:09:48PM +0800, "taoyi.ty" <escape-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> wrote:
> I found that rename(2) can be used in cgroup v1 but is disallowed in cgroup
> v2, what's the reason for this design?

There's some info in the commit 6db8e85c5c1f89cd0183b76dab027c81009f129f.

> rename(2) is critical when managing a cgroup pool in userspace, which uses
> rename to reuse cgroup rather than mkdir to create a new one，

Strictly speaking, it's not critical if you decouple your job and cgroup
naming scheme (i.e. use the cgroup with the old name).

> this can improve the performance of container concurrent startup,
> because renaming cgroup is much more lightweight compared with
> creating cgroup.

Do you have some numbers for this?
You can save work with not rmdir/mkdir'ing but you mention
concurrent startup specifically. And you still need to (re)setup
the cgroups after reuse and that also isn't parallelizable (at least you
need to (re)populate each reused cgroup, which is mostly under one
lock). (Even cgroup1_rename() has an exclusive section under
cgroup_mutex but it looks relatively simply.)


Michal

Re: Question about disallowing rename(2) in cgroup v2

[taoyi.ty]

Hi, Michal

Thanks for your reply.

在 7/15/22 8:45 PM, Michal Koutný 写道:
> Strictly speaking, it's not critical if you decouple your job and cgroup
> naming scheme (i.e. use the cgroup with the old name).

Though using the cgroup with the old name is ok, but naming rule of 
cgroup used by container is containerd-<ID>, it's confusing for 
different containers to use cgroup with same name

> Do you have some numbers for this?
For 200 container concurrent startup, it can reduce 94% of the cgroups 
creation time if using cgroup pool based on cgroup1_rename(). More 
detail data can be seen in section 3.3 and 4.4 of 
https://www.usenix.org/system/files/atc22-li-zijun-rund.pdf

> You can save work with not rmdir/mkdir'ing but you mention
> concurrent startup specifically. And you still need to (re)setup
> the cgroups after reuse and that also isn't parallelizable (at least you
> need to (re)populate each reused cgroup, which is mostly under one
> lock). (Even cgroup1_rename() has an exclusive section under
> cgroup_mutex but it looks relatively simply.)
Yes, reusing cgroup isn't parallelizable, it just eases but doesn’t 
solve the underlying problem. The current bottleneck has been solved 
temporarily by cgroup pool, how to make creating cgroup and attaching 
tasks parallelizable requires more thought and research

Thanks.

Escape