On Wed, May 27, 2026 at 03:10:47PM -0400, Eric Chanudet <[email protected]> wrote: > but that made me realize there is a catch with > this patch set, with something like: > A: +memory{max:32M}/+dmem > A/B: +memory{max:16M} > > It gets the CSS from the dmem's cgroup with > cgroup_get_e_css(cgrp, &memory_cgrp_subsys); > mem_cgroup_from_css(mem_css); > > Which would resolve to A's memcg and not enforce the memory.max limit > set in B when dmem.memcg is set for that region.
One perspective is that this is in accordance with dmem's limit granularity. If the user wanted to distinguish dmem charges below A, they need to enable the controller there too. IOW, the depends_on in one direction is correct. dmem is primary when it comes to those charges and memcg secondary. Another possibility would be to always use the highest precision available (wrt where current resides) and then the API should refer to struct cgroup from task_dfl_cgroup(current) (and make this only available on v2), or to struct css_set and extract respective subsys csses in the double charging function. In either case, it's worth mentioning the behavior in the dmem docs. HTH, Michal
signature.asc
Description: PGP signature
