On 3/2/26 16:40, Shakeel Butt wrote: > +TJ > > On Mon, Mar 02, 2026 at 03:37:37PM +0100, Christian König wrote: >> On 3/2/26 15:15, Shakeel Butt wrote: >>> On Wed, Feb 25, 2026 at 10:09:55AM +0100, Christian König wrote: >>>> On 2/24/26 20:28, Dave Airlie wrote: >>> [...] >>>> >>>>> This has been a pain in the ass for desktop for years, and I'd like to >>>>> fix it, the HPC use case if purely a driver for me doing the work. >>>> >>>> Wait a second. How does accounting to cgroups help with that in any way? >>>> >>>> The last time I looked into this problem the OOM killer worked based on >>>> the per task_struct stats which couldn't be influenced this way. >>>> >>> >>> It depends on the context of the oom-killer. If the oom-killer is triggered >>> due >>> to memcg limits then only the processes in the scope of the memcg will be >>> targetted by the oom-killer. With the specific setting, the oom-killer can >>> kill >>> all the processes in the target memcg. >>> >>> However nowadays the userspace oom-killer is preferred over the kernel >>> oom-killer due to flexibility and configurability. Userspace oom-killers >>> like >>> systmd-oomd, Android's LMKD or fb-oomd are being used in containerized >>> environments. Such oom-killers looks at memcg stats and hiding something >>> something from memcg i.e. not charging to memcg will hide such usage from >>> these >>> oom-killers. >> >> Well exactly that's the problem. Android's oom killer is *not* using memcg >> exactly because of this inflexibility. > > Are you sure Android's oom killer is not using memcg? From what I see in the > documentation [1], it requires memcg.
My bad, I should have been wording that better. The Android OOM killer is not using memcg for tracking GPU memory allocations, because memcg doesn't have proper support for tracking shared buffers. In other words GPU memory allocations are shared by design and it is the norm that the process which is using it is not the process which has allocated it. What we would need (as a start) to handle all of this with memcg would be to accounted the resources to the process which referenced it and not the one which allocated it. I can give a full list of requirements which would be needed by cgroups to cover all the different use cases, but it basically means tons of extra complexity. Regards, Christian. > > [1] https://source.android.com/docs/core/perf/lmkd > >> >> See the multiple iterations we already had on that topic. Even including >> reverting already upstream uAPI. >> >> The latest incarnation is that BPF is used for this task on Android. >> >> Regards, >> Christian.
