Hello, On Fri, Sep 10, 2021 at 10:11:53AM +0800, taoyi.ty wrote: > The scenario is the function computing of the public > cloud. Each instance of function computing will be > allocated about 0.1 core cpu and 100M memory. On > a high-end server, for example, 104 cores and 384G, > it is normal to create hundreds of containers at the > same time if burst of requests comes. This type of use case isn't something cgroup is good at, at least not currently. The problem is that trying to scale management operations like creating and destroying cgroups has implications on how each controller is implemented - we want the hot paths which get used while cgroups are running actively to be as efficient and scalable as possible even if that requires a lot of extra preparation and lazy cleanup operations. We don't really want to push for cgroup creation / destruction efficiency at the cost of hot path overhead. This has implications for use cases like you describe. Even if the kernel pre-prepare cgroups to low latency for cgroup creation, it means that the system would be doing a *lot* of managerial extra work creating and destroying cgroups constantly for not much actual work. Usually, the right solution for this sort of situations is pooling cgroups from the userspace which usually has a lot better insight into which cgroups can be recycled and can also adjust the cgroup hierarchy to better fit the use case (e.g. some rapid-cycling cgroups can benefit from higher-level resource configurations). So, it'd be great to make the managerial operations more efficient from cgroup core side but there are inherent architectural reasons why rapid-cycling use cases aren't and won't be prioritized. Thanks. -- tejun
