On Thu, May 15, 2025 at 01:02:07PM +1000, Dave Airlie wrote: > > I have to admit I'm pretty clueless about the gpu driver internals and > > can't really judge how feasible this is. But from a cgroup POV, if you > > want proper memory isolation between groups, it seems to me that's the > > direction you'd have to take this in. > > Thanks for this insight, I think you have definitely shown me where > things need to go here, and I agree that the goal should be to make > the pools and the shrinker memcg aware is the proper answer, > unfortunately I think we are long way from that at the moment, but > I'll need to do a bit more research.
Per-cgroup LRUs are quite common, so we have a lib to make this easy. Take a look at <linux/list_lru.h>. It provides a list type as a replacement for the bare struct list_head, along with list_lru_add(), list_lru_del() helpers. Call memcg_list_lru_alloc() before adding objects, this makes sure the internal per-cgroup data structures are all set up. list_lru_add()/del() take a memcg argument, so you have to work out how you want to plumb that down. page->memcg still sounds easiest to me. That doesn't mean you have to use __GFP_ACCOUNT, considering the dma allocation path; You can always memcg_kmem_charge_page() them by hand after the allocation is done, which will set up the backptr. For the shrinker itself, there are list_lru_shrink_count() and list_lru_shrink_walk() helpers which are designed to slot right into the shrinker callbacks. You only have to implement the callback to isolate an item - this is where the LRU specific locking and reclaim rules live, but that should be straight forward in your case.
