Re: [PATCH 07/16] memcg: add support for GPU page counters. (v4)

["Christian König" <christian.koenig@amd.com>]

On 3/5/26 04:19, Dave Airlie wrote:
>> Independent of all of that, memcg doesn't really work well for this
>> because it's shared memory that can only be attributed to a single
>> memcg, and the most common allocator (gralloc) is in a separate
>> process and memcg than the processes using the buffers (camera,
>> YouTube, etc.). I had a few patches that transferred the ownership of
>> buffers to a new memcg when they were sent via Binder, but this used
>> the memcg v1 charge moving functionality which is now gone because it
>> was so complicated. But that only works if there is one user that
>> should be charged for the buffer anyway. What if it is shared by
>> multiple applications and services?
>>
> 
> Usually there is a user intent behind the action that causes the
> memory allocation, i.e. user opens camera app, user runs instagram
> which opens camera, and uses GPU filters etc.
> 
> The charge should be to the application or cgroup that causes the
> intent, if multiple applications/services are sharing a buffer, what
> is the intent behind how that happens, is there a limit on how to make
> more of those shared buffers get allocated, what drives that etc.

Well the problem is that by charging to the process allocating things the kernel only makes an educated guess what the intent is.

As far as I can see that approach only works for containers but basically not for a huge bunch of other use cases.

Taking the Android use case T.J. describes as example what you would need there is to charge against is the file descriptor and not the application. The application only comes into the picture when you then want to know what is the total of what a specific process uses.

Same thing for native context for automotive, here it is even worse since the role separation is different and you never even ask what the application uses because that is completely uninteresting for that use case. But you still want some kind of limitation for each use case.

> If there are truly internal memory allocations like evictions or
> underlying shared pages tables then maybe we don't have to account
> those to a specific application, but we really want to make sure a
> user intentionally cannot cause an application to consume more memory,
> so at least for Android I'd try and tie it to user actions and account
> to that process.
> 
> On desktop Linux, I would say firefox or gtk apps are the intended
> users of any compositor allocated buffers (not that we really have
> those now I don't think).
> 
> if there are caches of allocations that should also be tied into
> cgroups, so memory pressure can reclaim them.

Not if the cache is global for all cgroups. Tying caches to cgroups only makes sense if that cache is beneficial to that specific cgroup.

In other words you need to distinct between caches (which contain cgroup specific data) and memory pools or caches which doesn't contain any data.

Regards,
Christian.

> 
> Dave.