All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@suse.cz
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	rientjes@google.com, hannes@cmpxchg.org
Subject: Re: [PATCH] mm: Don't emit warning from pagefault_out_of_memory()
Date: Mon, 12 Sep 2016 20:32:13 +0900	[thread overview]
Message-ID: <201609122032.GCI56728.OJFHFtMLVOQSOF@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20160912071651.GB14524@dhcp22.suse.cz>

Michal Hocko wrote:
> On Sat 10-09-16 02:28:40, Tetsuo Handa wrote:
> > Commit c32b3cbe0d067a9c ("oom, PM: make OOM detection in the freezer path
> > raceless") inserted a WARN_ON() into pagefault_out_of_memory() in order
> > to warn when we raced with disabling the OOM killer. But emitting same
> > backtrace forever after the OOM killer/reaper are disabled is pointless
> > because the system is already OOM livelocked.
> 
> How that would that be forever? Pagefaults are not GFP_NOFAIL and the
> killed task would just enter the exit path.

Indeed, there is

	/* Avoid allocations with no watermarks from looping endlessly */
	if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
		goto nopage;

check.

I don't know if pagefaults can happen after entering do_exit().
If pagefaults can happen after entering do_exit(), can
pagefault_out_of_memory() by PF_EXITING threads make progress
without allocating that page?

>                                             Sure we will see one warning
> per each g-u-p after that point but the above text seems to be
> misleading to me. So can you just drop the last sentence?
> 
> > Now, patch "oom, suspend: fix oom_killer_disable vs. pm suspend properly"
> > introduced a timeout for oom_killer_disable(). Even if we raced with
> > disabling the OOM killer and the system is OOM livelocked, the OOM killer
> > will be enabled eventually (in 20 seconds by default) and the OOM livelock
> > will be solved. Therefore, we no longer need to warn when we raced with
> > disabling the OOM killer.
> 
> That being said I guess the warning is really no longer needed as you
> say. So I am not against the patch. But the changelog wording seems
> misleading to me.

I see. Only patch description was updated.
----------------------------------------
Subject: [PATCH v2] mm: Don't emit warning from pagefault_out_of_memory()
Date: Sat, 10 Sep 2016 02:28:40 +0900
Message-Id: <1473442120-7246-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>

Commit c32b3cbe0d067a9c ("oom, PM: make OOM detection in the freezer path
raceless") inserted a WARN_ON() into pagefault_out_of_memory() in order
to warn when we raced with disabling the OOM killer.

Now, patch "oom, suspend: fix oom_killer_disable vs. pm suspend properly"
introduced a timeout for oom_killer_disable(). Even if we raced with
disabling the OOM killer and the system is OOM livelocked, the OOM killer
will be enabled eventually (in 20 seconds by default) and the OOM livelock
will be solved. Therefore, we no longer need to warn when we raced with
disabling the OOM killer.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
---
 mm/oom_kill.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 0034baf..f284e92 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1069,16 +1069,6 @@ void pagefault_out_of_memory(void)
 
 	if (!mutex_trylock(&oom_lock))
 		return;
-
-	if (!out_of_memory(&oc)) {
-		/*
-		 * There shouldn't be any user tasks runnable while the
-		 * OOM killer is disabled, so the current task has to
-		 * be a racing OOM victim for which oom_killer_disable()
-		 * is waiting for.
-		 */
-		WARN_ON(test_thread_flag(TIF_MEMDIE));
-	}
-
+	out_of_memory(&oc);
 	mutex_unlock(&oom_lock);
 }
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-09-12 12:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 17:28 Tetsuo Handa
2016-09-12  7:16 ` Michal Hocko
2016-09-12 11:32   ` Tetsuo Handa [this message]
2016-09-12 11:51     ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201609122032.GCI56728.OJFHFtMLVOQSOF@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=rientjes@google.com \
    --subject='Re: [PATCH] mm: Don'\''t emit warning from pagefault_out_of_memory()' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.