Hi, On Tue, Apr 4, 2017 at 12:40 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Mon 03-04-17 11:09:32, Doug Anderson wrote: > [...] >> Maybe +Michal Hocko would have some opinions of which OOM Reaper >> patches would be good for picking into linux stable? > > I am lacking context here but please note that the OOM reaper patches > alone are not sufficient to make the OOM handling lockup free. There > were quite some changes in the core OOM killer handling to make this > possible. This has been work throughout the last year and it will be > really non-trivial to backport to stable trees. Yeah, that was the impression I got. > So the primary question is what are you trying to achieve? Ideally it would be nice to bring back patches to make the OOM handling lockup free. However, presuming that's not feasible then at least it would be nice if we could get some minimal set of patches that: - Isn't too scary to backport. - Handles the low hanging fruit. - Is fairly self contained. For Chrome OS we've got devices on a number of different kernels ranging from 3.8 - 4.4. Due to changes in userspace, it appears much more likely that we wedge the OOM killer these days, so my main goal is to avoid this in most cases. Right now for Chrome OS I have patches that look like this: * https://chromium-review.googlesource.com/465186 UPSTREAM: mm: oom_kill: don't ignore oom score on exiting tasks * https://chromium-review.googlesource.com/465187 CHROMIUM: DROP: mm/oom_kill: Don't kill a subthread in our place if we still ... * https://chromium-review.googlesource.com/465188 CHROMIUM: DROP: mm/oom_kill: Double-check before killing a child in our place * https://chromium-review.googlesource.com/465189 CHROMIUM: DROP: mm/oom_kill: Avoid deadlock; allow multiple victims ...and those seem to fit the bill for us, but: 1. It would be nice if other users of linuxstable could benefit. 2. I know the above patches are not as ideal as the work that has happened upstream, so of course I'd prefer to get the upstream solution. 3. I always appreciate being closer to the upstream solution which means we get more people looking at the code and more people testing the code. -Doug _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
