Re: [RFC PATCH 0/2] support cgroup pool in v1

[taoyi.ty]

I am glad to receive your reply.

cgroup pool is a relatively simple solution that I think can

solve the problem.

I have tried making locking more granular, but in the end found

it too diffcult. cgroup_mutex protects almost all operation related

to cgroup. If not use cgroup_mutex, I have no idea how to design

lock mechanism to take both concurrent performance and

existing interfaces into account. Do you have any good advice?


thanks,


Yi Tao


On 2021/9/9 上午12:35, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 08, 2021 at 08:15:11PM +0800, Yi Tao wrote:
> > In order to solve this long-tail delay problem, we designed a cgroup
> > pool. The cgroup pool will create a certain number of cgroups in advance.
> > When a user creates a cgroup through the mkdir system call, a clean cgroup
> > can be quickly obtained from the pool. Cgroup pool draws on the idea of
> > cgroup rename. By creating pool and rename in advance, it reduces the
> > critical area of cgroup creation, and uses a spinlock different from
> > cgroup_mutex, which reduces scheduling overhead on the one hand, and eases
> > competition with attaching processes on the other hand.
> I'm not sure this is the right way to go about it. There are more
> conventional ways to improve scalability - making locking more granular and
> hunting down specific operations which take long time. I don't think cgroup
> management operations need the level of scalability which requires front
> caching.
>
> Thanks.