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