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