[rfc] drm/ttm/memcg: simplest initial memcg/ttm integration (v2)
Shakeel Butt
shakeel.butt at linux.dev
Tue May 6 00:37:51 UTC 2025
On Fri, May 02, 2025 at 01:35:59PM +1000, Dave Airlie wrote:
> Hey all,
>
> This is my second attempt at adding the initial simple memcg/ttm
> integration.
>
> This varies from the first attempt in two major ways:
>
> 1. Instead of using __GFP_ACCOUNT and direct calling kmem charges
> for pool memory, and directly hitting the GPU statistic,
Why was the first attempt abandoned? What was the issue with the above
approach?
> Waiman
> suggested I just do what the network socket stuff did, which looks
> simpler. So this adds two new memcg apis that wrap accounting.
> The pages no longer get assigned the memcg, it's owned by the
> larger BO object which makes more sense.
The issue with this approach is that this new stat is only exposed in
memcg. For networking, there are interfaces like /proc/net/sockstat and
/proc/net/protocols which expose system wide network memory usage. I
think we should expose this new "memory used by gpus" at the system
level possibly through /proc/meminfo.
>
> 2. Christian suggested moving it up a layer to avoid the pool business,
> this was a bit tricky, since I want the gfp flags, but I think it only
> needs some of them and it should work. One other big difference is that
> I aligned it with the dmem interaction, where it tries to get space in
> the memcg before it has even allocated any pages,
I don't understand the memcg reference in the above statement. Dmem is a
separate cgroup controller orthogonal to memcg.
> I'm not 100% sure
> this is how things should be done, but it was easier, so please let
> me know if it is wrong.
>
> This still doesn't do anything with evictions except ignore them,
> and I've some follows up on the old thread to discuss more on them.
>
> Dave.
>
More information about the dri-devel
mailing list