Hello, I don't think we want to define dmem.high (or dmem.max) in terms of a specific reclaim mechanic. These interface files should express a generic resource-distribution concept that stays valid regardless of how the underlying reclaim works. As written, dmem.high comes down to "evicted first in the high-priority eviction pass". It isn't consulted on charge and dmem has no proactive reclaim, so the file does nothing until a dmem.max hit elsewhere triggers eviction. That's an implementation detail, not something I'd want to commit to in the cgroup interface.
It also reads as a way to work around dmem's reclaim behavior rather than a soft limit in its own right. A dmem.max hit doesn't just fail today: the charge returns -EAGAIN and TTM already falls back to evicting buffers and retrying before the allocation fails. So the question isn't "max fails immediately, add reclaim via high" but which buffers reclaim should target and when, which is a property of the max reclaim behavior. If we work around that with a high knob whose meaning is the current eviction order, we bake an implementation detail into the ABI and make it harder to give dmem.high a proper soft-limit semantics later. I'm not against a dmem soft limit. I'd rather improve the max reclaim behavior so it makes sense in general, and then define high as a concept on top of that, rather than the other way around. The whole max-vs-high distinction and what a soft limit should mean has had a lot of thought put into it on the memcg side, so adding the memcg folks for their input. Thanks. -- tejun
