Re: [PATCH] mm, oom: simplify alloc_pages_before_oomkill handling

[Tetsuo Handa]

Michal Hocko wrote:
> Recently added alloc_pages_before_oomkill gained new caller with this
> patchset and I think it just grown to deserve a simpler code flow.
> What do you think about this on top of the series?

I'm planning to post below patch in order to mitigate OOM lockup problem
caused by scheduling priority. But I'm OK with your patch because your patch
will not conflict with below patch.

----------
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b2746a7..ef6e951 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3332,13 +3332,14 @@ 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.
+	 * Acquire the oom lock. If that fails, give enough CPU time to the
+	 * owner of the oom lock in order to help reclaiming memory.
 	 */
-	if (!mutex_trylock(&oom_lock)) {
-		*did_some_progress = 1;
+	while (!mutex_trylock(&oom_lock)) {
+		page = alloc_pages_before_oomkill(oc);
+		if (page)
+			return page;
 		schedule_timeout_uninterruptible(1);
-		return NULL;
 	}
 
 	/* Coredumps can quickly deplete all memory reserves */
----------