[rfc] drm/ttm/memcg: simplest initial memcg/ttm integration

[Christian König]

On 4/23/25 23:37, Dave Airlie wrote:
> Hey,
> 
> I've been tasked to look into this, and I'm going start from hopeless
> naivety and see how far I can get. This is an initial attempt to hook
> TTM system memory allocations into memcg and account for them.

Yeah, this looks mostly like what we had already discussed.

> 
> It does:
> 1. Adds memcg GPU statistic,
> 2. Adds TTM memcg pointer for drivers to set on their user object
> allocation paths
> 3. Adds a singular path where we account for memory in TTM on cached
> non-pooled non-dma allocations. Cached memory allocations used to be
> pooled but we dropped that a while back which makes them the best target
> to start attacking this from.

I think that should go into the resource like the existing dmem approach instead. That allows drivers to control the accounting through the placement which is far less error prone than the context.

It would also completely avoid the pooled vs unpooled problematic.


> 4. It only accounts for memory that is allocated directly from a userspace
> TTM operation (like page faults or validation). It *doesn't* account for
> memory allocated in eviction paths due to device memory pressure.

Yeah, that's something I totally agree on.

But the major show stopper is still accounting to memcg will break existing userspace. E.g. display servers can get attacked with a deny of service with that.

The feature would need to be behind a module option or not account allocations for DRM masters or something like that.

> 
> This seems to work for me here on my hacked up tests systems at least, I
> can see the GPU stats moving and they look sane.
> 
> Future work:
> Account for pooled non-cached
> Account for pooled dma allocations (no idea how that looks)
> Figure out if accounting for eviction is possible, and what it might look
> like.

T.J. suggested to account but don't limit the evictions and I think that should work.

Regards,
Christian.

> 
> Dave.
>