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
