>From c3b6616238fcd65d5a0fdabcb4577c7e6f40d35e Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> Date: Tue, 20 Feb 2018 11:07:23 +0900 Subject: [PATCH] mm,page_alloc: wait for oom_lock than back off This patch fixes a bug which is essentially same with a bug fixed by commit 400e22499dd92613 ("mm: don't warn about allocations which stall for too long"). Currently __alloc_pages_may_oom() is using mutex_trylock(&oom_lock) based on an assumption that the owner of oom_lock is making progress for us. But it is possible to trigger OOM lockup when many threads concurrently called __alloc_pages_slowpath() because all CPU resources are wasted for pointless direct reclaim efforts. That is, schedule_timeout_uninterruptible(1) in __alloc_pages_may_oom() does not always give enough CPU resource to the owner of the oom_lock. It is possible that the owner of oom_lock is preempted by other threads. Preemption makes the OOM situation much worse. But the page allocator is not responsible about wasting CPU resource for something other than memory allocation request. Wasting CPU resource for memory allocation request without allowing the owner of oom_lock to make forward progress is a page allocator's bug. Therefore, this patch changes to wait for oom_lock in order to guarantee that no thread waiting for the owner of oom_lock to make forward progress will not consume CPU resources for pointless direct reclaim efforts. Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> Cc: Johannes Weiner <hannes@xxxxxxxxxxx> Cc: Michal Hocko <mhocko@xxxxxxxx> Cc: David Rientjes <rientjes@xxxxxxxxxx> --- mm/page_alloc.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e2b42f6..0cd48ae6 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3350,11 +3350,7 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...) *did_some_progress = 0; - /* - * Acquire the oom lock. If that fails, somebody else is - * making progress for us. - */ - if (!mutex_trylock(&oom_lock)) { + if (mutex_lock_killable(&oom_lock)) { *did_some_progress = 1; schedule_timeout_uninterruptible(1); return NULL; -- 1.8.3.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>