On Tue, 11 Mar 2025 at 00:26, Maxime Ripard <mrip...@kernel.org> wrote: > > Hi, > > On Mon, Mar 10, 2025 at 03:16:53PM +0100, Christian König wrote: > > [Adding Ben since we are currently in the middle of a discussion > > regarding exactly that problem] > > > > Just for my understanding before I deep dive into the code: This uses > > a separate dmem cgroup and does not account against memcg, don't it? > > Yes. The main rationale being that it doesn't always make sense to > register against memcg: a lot of devices are going to allocate from > dedicated chunks of memory that are either carved out from the main > memory allocator, or not under Linux supervision at all. > > And if there's no way to make it consistent across drivers, it's not the > right tool. >
While I agree on that, if a user can cause a device driver to allocate memory that is also memory that memcg accounts, then we have to interface with memcg to account that memory. The pathological case would be a single application wanting to use 90% of RAM for device allocations, freeing it all, then using 90% of RAM for normal usage. How to create a policy that would allow that with dmem and memcg is difficult, since if you say you can do 90% on both then the user can easily OOM the system. Dave. > Maxime
