Hello, On Tue, Sep 21, 2021 at 03:44:14PM +0200, Michal Koutný wrote: > On 2021/09/18 3:58, Khazhy Kumykov wrote: > > (This does also bring up: if this is a useful thing, would it make > > sense to tie to the device, vs. requiring cgroup. We happen to use > > cgroups so that requirement doesn't affect us). > > Good point, That's IMO a better idea, it'd be more consistent with other > resources for which there exist global (cgroup independent) kernel > constraints (e.g. threads-max sysctl, mem= cmdline, cpu hotplug) that > double the root cgroup contraint role. This is why I usually try to push root-cgroup level features outside cgroup because it really doesn't have much to do with cgroups at the root level. For visibility stuff, we do replicate quite a bit in the root level because not doing so becomes too painful for users but for control I'm more hesitant. One side-way solution could be using iocost. It doesn't have root-level control per-se but it does configure per-device attributes which define what the device can and is allowed to do so that it can be used as the basis for weighted fair distribution. Even if IO control is disabled from the root level, it'll still modulate the device according to the parameters. > OTOH, this also deepens the precedent of init NS root cgroup being > special (more special than a container's root cgroup). While it does seem like an aesthetical wrinkle, I don't think this is a practical problem. System root being different is a given whether aesthetically pleasing or not (not the most important but we have CONFIG_CGROUPS after all). I don't think it'll lead anywhere good to try to mask the differences. Thanks. -- tejun
