On Wed 21-04-21 19:05:49, peter enderborg wrote: [...] > I think this is the wrong way to go. > > I sent a patch for android lowmemorykiller some years ago. > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2017-February/100319.html > > It has been improved since than, so it can act handle oom callbacks, it can act on vmpressure and psi > and as a shrinker. The patches has not been ported to resent kernels though. > > I don't think vmpressure and psi is that relevant now. (They are what userspace act on) But the basic idea is to have a priority queue > within the kernel. It need pick up new processes and dying process. And then it has a order, and that > is set with oom adj values by activity manager in android. I see this model can be reused for > something that is between a standard oom and userspace. Instead of vmpressure and psi > a watchdog might be a better way. If userspace (in android the activity manager or lmkd) does not kick the watchdog, > the watchdog bite the task according to the priority and kills it. This priority list does not have to be a list generated > within kernel. But it has the advantage that you inherent parents properties. We use a rb-tree for that. > > All that is missing is the watchdog. And this is off topic to the discussion as well. We are not discussing how to handle OOM situation best. Shakeel has brought up challenges that some userspace based OOM killer implementations are facing. Like it or not but different workloads have different requirements and what you are using in Android might not be the best fit for everybody. I will not comment on the android approach but it doesn't address any of the concerns that have been brought up. -- Michal Hocko SUSE Labs
