On Tue, 24 Feb 2026 at 17:50, Christian König <[email protected]> wrote: > > On 2/24/26 03:06, Dave Airlie wrote: > > From: Dave Airlie <[email protected]> > > > > This introduces 2 new statistics and 3 new memcontrol APIs for dealing > > with GPU system memory allocations. > > > > The stats corresponds to the same stats in the global vmstat, > > for number of active GPU pages, and number of pages in pools that > > can be reclaimed. > > > > The first API charges a order of pages to a objcg, and sets > > the objcg on the pages like kmem does, and updates the active/reclaim > > statistic. > > > > The second API uncharges a page from the obj cgroup it is currently charged > > to. > > > > The third API allows moving a page to/from reclaim and between obj cgroups. > > When pages are added to the pool lru, this just updates accounting. > > When pages are being removed from a pool lru, they can be taken from > > the parent objcg so this allows them to be uncharged from there and > > transferred > > to a new child objcg. > > > > Acked-by: Christian König <[email protected]> > > I have to take that back. > > After going over the different use cases I'm now pretty convinced that > charging any GPU/TTM allocation to memcg is the wrong approach to the problem.
You'll need to sell me a bit more on this idea, I don't hate it, but it seems to be honest kinda half baked and smells a bit of reachitect without form, so please start up you writing skills and give me something concrete here. > > Instead TTM should have a dmem_cgroup_pool which can limit the amount of > system memory each cgroup can use from GTT. This sounds like a static limit though, how would we configure that in a sane way? > > The use case that GTT memory should account to memcg is actually only valid > for an extremely small number of HPC customers and for those use cases we > have different approaches to solve this issue (udmabuf, system DMA-buf heap, > etc...). Stop, I have a major use case for this that isn't any of those. Integrated GPUs on Intel and AMD accounting the RAM usage to somewhere useful, so cgroup mgmt of desktop clients actually work, so when firefox uses GPU memory it gets accounted to firefox and when the OOM killer comes along it can choose the correct user. This has been a pain in the ass for desktop for years, and I'd like to fix it, the HPC use case if purely a driver for me doing the work. Can you give a detailed explanation of how your idea will work in an unconfigured cgroup environment to help this case? > > What we can do is to say that this dmem_cgroup_pool then also accounts to > memcg for selected cgroups. This would not only make it superflous to have > different flags in drivers and TTM to turn this feature on/off, but also > allow charging VRAM or other local memory to memcg because they use system > memory as fallback for device memory. > > In other more high level words memcg is actually the swapping space for dmem. This is descriptive, but still feels very static, and nothing I've seen indicated I want this to be a 50% type limit. Dave. >
