summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorMichal Hocko <mhocko@suse.com>2018-08-18 01:49:04 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2018-08-18 02:20:32 +0300
commit9bfe5ded054b8e28a94c78580f233d6879a00146 (patch)
tree0ad9d7261ab77ac01995e16abc1564c1d14bc872 /include/linux
parentd834c5ab83febf9624ad3b16c3c348aa1e02014c (diff)
downloadlinux-9bfe5ded054b8e28a94c78580f233d6879a00146.tar.xz
mm, oom: remove sleep from under oom_lock
Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent munlock and oom reaper unmap, v3") we have a strong synchronization between the oom_killer and victim's exiting because both have to take the oom_lock. Therefore the original heuristic to sleep for a short time in out_of_memory doesn't serve the original purpose. Moreover Tetsuo has noticed that the short sleep can be more harmful than actually useful. Hammering the system with many processes can lead to a starvation when the task holding the oom_lock can block for a long time (minutes) and block any further progress because the oom_reaper depends on the oom_lock as well. Drop the short sleep from out_of_memory when we hold the lock. Keep the sleep when the trylock fails to throttle the concurrent OOM paths a bit. This should be solved in a more reasonable way (e.g. sleep proportional to the time spent in the active reclaiming etc.) but this is much more complex thing to achieve. This is a quick fixup to remove a stale code. Link: http://lkml.kernel.org/r/20180709074706.30635-1-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions