linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Michal Hocko <mhocko@suse.cz>, Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>, <stable@vger.kernel.org>,
	Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 1/2] mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed
Date: Fri, 19 Dec 2014 21:28:15 +0300	[thread overview]
Message-ID: <20141219182815.GK18274@esperanza> (raw)
In-Reply-To: <20141219155747.GA31756@dhcp22.suse.cz>

Hi,

On Fri, Dec 19, 2014 at 04:57:47PM +0100, Michal Hocko wrote:
> On Fri 19-12-14 14:01:55, Vlastimil Babka wrote:
> > Charles Shirron and Paul Cassella from Cray Inc have reported kswapd stuck
> > in a busy loop with nothing left to balance, but kswapd_try_to_sleep() failing
> > to sleep. Their analysis found the cause to be a combination of several
> > factors:
> > 
> > 1. A process is waiting in throttle_direct_reclaim() on pgdat->pfmemalloc_wait
> > 
> > 2. The process has been killed (by OOM in this case), but has not yet been
> >    scheduled to remove itself from the waitqueue and die.
> 
> pfmemalloc_wait is used as wait_event and that one uses
> autoremove_wake_function for wake ups so the task shouldn't stay on the
> queue if it was woken up. Moreover pfmemalloc_wait sleeps are killable
> by the OOM killer AFAICS.
> 
> $ git grep "wait_event.*pfmemalloc_wait"
> mm/vmscan.c:
> wait_event_interruptible_timeout(pgdat->pfmemalloc_wait,
> mm/vmscan.c:    wait_event_killable(zone->zone_pgdat->pfmemalloc_wait,))
> 
> So OOM killer would wake it up already and kswapd shouldn't see this
> task on the waitqueue anymore.

OOM killer will wake up the process, but it won't remove it from the
pfmemalloc_wait queue. Therefore, if kswapd gets scheduled before the
dying process, it will see the wait queue being still active, but won't
be able to wake anyone up, because the waiting process has already been
woken by SIGKILL. I think this is what Vlastimil means.

So AFAIU the problem does exist. However, I think it could be fixed by
simply waking up all processes waiting on pfmemalloc_wait before putting
kswapd to sleep:

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 744e2b491527..2a123634c220 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2984,6 +2984,9 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int order, long remaining,
 	if (remaining)
 		return false;
 
+	if (!pgdat_balanced(pgdat, order, classzone_idx))
+		return false;
+
 	/*
 	 * There is a potential race between when kswapd checks its watermarks
 	 * and a process gets throttled. There is also a potential race if
@@ -2993,12 +2996,9 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int order, long remaining,
 	 * so wake them now if necessary. If necessary, processes will wake
 	 * kswapd and get throttled again
 	 */
-	if (waitqueue_active(&pgdat->pfmemalloc_wait)) {
-		wake_up(&pgdat->pfmemalloc_wait);
-		return false;
-	}
+	wake_up_all(&pgdat->pfmemalloc_wait);
 
-	return pgdat_balanced(pgdat, order, classzone_idx);
+	return true;
 }
 
 /*

  reply	other threads:[~2014-12-19 18:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-19 13:01 [PATCH 1/2] mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed Vlastimil Babka
2014-12-19 13:01 ` [PATCH 2/2] mm, vmscan: wake up all pfmemalloc-throttled processes at once Vlastimil Babka
2014-12-19 15:57 ` [PATCH 1/2] mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed Michal Hocko
2014-12-19 18:28   ` Vladimir Davydov [this message]
2014-12-19 23:05     ` Vlastimil Babka
2014-12-20  9:24       ` Vladimir Davydov
2014-12-20 10:47     ` Michal Hocko
2014-12-20 14:18       ` Vladimir Davydov
2014-12-22 14:24         ` Michal Hocko
2014-12-22 16:25           ` Vladimir Davydov
2014-12-22 19:33             ` Vlastimil Babka
2014-12-23 10:16             ` 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=20141219182815.GK18274@esperanza \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).