On Tue 03-07-18 17:12:23, Michal Hocko wrote: > On Tue 03-07-18 23:25:01, Tetsuo Handa wrote: > > This series provides > > > > (1) Mitigation and a fix for CVE-2016-10723. > > > > (2) A mitigation for needlessly selecting next OOM victim reported > > by David Rientjes and rejected by Michal Hocko. > > > > (3) A preparation for handling many concurrent OOM victims which > > could become real by introducing memcg-aware OOM killer. > > It would have been great to describe the overal design in the cover > letter. So let me summarize just to be sure I understand the proposal. > You are removing the oom_reaper and moving the oom victim tear down to > the oom path. To handle cases where we cannot get mmap_sem to do that > work you simply decay oom_badness over time if there are no changes in > the victims oom score. Correction. You do not decay oom_badness. You simply increase a stall counter anytime oom_badness hasn't changed since the last check (if that check happend at least HZ/10 ago) and get the victim out of sight if the counter is larger than 30. This is where 3s are coming from. So in fact this is the low boundary while it might be considerably larger depending on how often we examine the victim. -- Michal Hocko SUSE Labs
