> 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. 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.
