On Mon, Jun 15, 2026 at 08:57:06AM -1000, Tejun Heo wrote: > On Mon, Jun 15, 2026 at 08:49:55AM -1000, Tejun Heo wrote: > > The canonical behavior for cgroup2 would be not failing the write at all > > even when the usage can't be brought down below the new max. Updating the > > target configuration and tracking the current usage are separate operations. > > The former should just set max and trigger reclaim and a writer should not > > assume that a successful write indicates that the usage is below the written > > max value. > > Sent too early. One of the reasons is that cgroup is hierarchical and there > can be multiple delegation layers and if you tie application of configuration > to immediate enforcement, some hierarchical control actions become racy and > awkward. > > Here's an example: Imagine a system agent trying to lower usage in a subtree > which contains multiple delegated containers. If max can be set below what > reclaim can achieve immediately, it can just set the max and if the usage is > still too high, can go around and e.g. kill some of the containers. If max > write fails, it'd have to kill and then try again and inbetween someone else > might push up the usage. > > Thanks. > > -- > tejun
Hi, Tejun. As far as I understood the patchset, it doesn't fail the write if it fails to reclaim. It sets the new max, then, if the write is blocking, starts reclaim and eventually returns after multiple attempts. But it still returns success. So I believe this is behaving as you would expect. Regards. Cascardo.
