On Wed, Mar 4, 2026 at 7:20 PM Dave Airlie <[email protected]> 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. > > 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.
Hi Dave, Yeah this is why I pursued charge transfer. Most of the time I think we'd be ok just charging the initial allocating application, but a separate allocator process in a different memcg actually performs the allocation ioctl, so the allocator process, not the application, gets charged for it. Without charge transfer functionality in memcg, all the charge ends up in gralloc's memcg and that doesn't work for applying limits to applications. There are some kernel-driven allocations, which I'm only aware of in drivers. These are by far the minority, so I don't think accounting them separately or not at all creates a significant gap. > 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. > > Dave.
