On Tue, Nov 11, 2025 at 10:01:37PM +0100, Michal Hocko wrote: > How does that differ from writing a limit that would cause a constant > memory reclaim from a worklad that you craft and cause a constant CPU > activity and even worse lock contention? > > I guess the answer is that you do not let untrusted entities to create > cgroup hierarchies and allow to modify or generally have a write access > to control files. Or am I missing something? This used to apply in cgroup v1 but the v2 controller APIs are meant to be available to anyone (e.g. rootless containers). So yes, if it turns out that the isolation may be substantially bypassed by reclaim, I think it should be solved by some rework. The memory.stat_refresh is different because it doesn't exist yet so its impact on isolation needn't be even potentially solved :-p (not more than memory.stat). --- That's also why memory.stat_refresh is different from one global vm/stat_refresh (easily constrained to root's monitoring tools). And despite this precedent, I don't like the approach of two independent invocations (write(2)+read(2)) when the intention [1] is to obtain precise data (at least) at the time of the read(2). Cheers, Michal [1] I guess. I'd still wait for what the actual usefulness besides fixing LTP here is.