Hello, Sorry about late reply.
On Wed, Apr 07, 2021 at 08:34:24PM +0200, Peter Zijlstra wrote: > > Given the existence of prctl and clone APIs, I don't see the reason to > > have a separate cgroup-bound interface too (as argued by Tejun). > > IMO as long as cgroups have that tasks file, you get to support people > using it. That means that tasks joining your cgroup need to 'inherit' This argument doesn't really make sense to me. We don't just add things to make interfaces orthogonal. It can be a consideration but not the only or even one of the most important ones. There are many cases we say to not shoot oneself in the foot and also many interfaces which are fading away or in the process of being deprecated. I'm not planning to deprecate the dynamic migration interfaces given the history and usefulness in testing but the usage model of cgroup2 is clearly defined and documented in this regard - whether the initial population of the cgroup happens through CLONE_INTO_CGROUP or migration, for resource tracking and control purposes, cgroup2 does not support dynamic migration with the exception of migrations within threaded domains. Anything is a possibility but given how this requirement is intertwined with achieveing comprehensive resource control, a core goal of cgroup2, and widely adopted by all the new fangled things as you put it, changing this wouldn't be easy. Not just because some people including me are against it but because there are inherent technical challenges and overheads to supporting dynamic charge migration for stateful controllers and the cost-benefit balance doesn't come out in favor. So, the current "policy" is something like this: * cgroupfs interface is for cgroup core features of organizing cgroups and processes and configuring resource configurations which preferably follow one of the control models defined in the doc. * The hierarchical organization is semi-static in the sense that once a cgroup is populated tasks shouldn't be moved in or out of the cgroup with the exception of threaded domains. * Non-resource control usages can hook into cgroup for identification / tagging purposes but should use the originating interface for interactions. This has been consistently applied over the years now. There of course can be exceptions but I haven't seen anything outstanding in this round of discussion so am pretty skeptical. The actual use cases don't seem to need it and the only argument for it is it'd be nice to have it and involves violating the usage model. My suggestion is going ahead with the per-process interface with cgroup extension on mind in case actual use cases arise. Also, when planning cgroup integration, putting dynamic migration front and center likely isn't a good idea. Thanks. -- tejun