From: Mel Gorman <mgorman@suse.de>
To: Colin Cross <ccross@android.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: avoid livelock on !__GFP_FS allocations
Date: Tue, 25 Oct 2011 11:09:56 +0200 [thread overview]
Message-ID: <20111025090956.GA10797@suse.de> (raw)
In-Reply-To: <1319524789-22818-1-git-send-email-ccross@android.com>
On Mon, Oct 24, 2011 at 11:39:49PM -0700, Colin Cross wrote:
> Under the following conditions, __alloc_pages_slowpath can loop
> forever:
> gfp_mask & __GFP_WAIT is true
> gfp_mask & __GFP_FS is false
> reclaim and compaction make no progress
> order <= PAGE_ALLOC_COSTLY_ORDER
>
> These conditions happen very often during suspend and resume,
> when pm_restrict_gfp_mask() effectively converts all GFP_KERNEL
> allocations into __GFP_WAIT.
b>
> The oom killer is not run because gfp_mask & __GFP_FS is false,
> but should_alloc_retry will always return true when order is less
> than PAGE_ALLOC_COSTLY_ORDER.
>
> Fix __alloc_pages_slowpath to skip retrying when oom killer is
> not allowed by the GFP flags, the same way it would skip if the
> oom killer was allowed but disabled.
>
> Signed-off-by: Colin Cross <ccross@android.com>
Hi Colin,
Your patch functionally seems fine. I see the problem and we certainly
do not want to have the OOM killer firing during suspend. I would prefer
that the IO devices would not be suspended until reclaim was completed
but I imagine that would be a lot harder.
That said, it will be difficult to remember why checking __GFP_NOFAIL in
this case is necessary and someone might "optimitise" it away later. It
would be preferable if it was self-documenting. Maybe something like
this? (This is totally untested)
mm/page_alloc.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6e8ecb6..ad8f376 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -127,6 +127,20 @@ void pm_restrict_gfp_mask(void)
saved_gfp_mask = gfp_allowed_mask;
gfp_allowed_mask &= ~GFP_IOFS;
}
+
+static bool pm_suspending(void)
+{
+ if ((gfp_allowed_mask & GFP_IOFS) == GFP_IOFS)
+ return false;
+ return true;
+}
+
+#else
+
+static bool pm_suspending(void)
+{
+ return false;
+}
#endif /* CONFIG_PM_SLEEP */
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
@@ -2207,6 +2221,14 @@ rebalance:
goto restart;
}
+
+ /*
+ * Suspend converts GFP_KERNEL to __GFP_WAIT which can
+ * prevent reclaim making forward progress without
+ * invoking OOM. Bail if we are suspending
+ */
+ if (pm_suspending())
+ goto nopage;
}
/* Check if we should retry the allocation */
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Colin Cross <ccross@android.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: avoid livelock on !__GFP_FS allocations
Date: Tue, 25 Oct 2011 11:09:56 +0200 [thread overview]
Message-ID: <20111025090956.GA10797@suse.de> (raw)
In-Reply-To: <1319524789-22818-1-git-send-email-ccross@android.com>
On Mon, Oct 24, 2011 at 11:39:49PM -0700, Colin Cross wrote:
> Under the following conditions, __alloc_pages_slowpath can loop
> forever:
> gfp_mask & __GFP_WAIT is true
> gfp_mask & __GFP_FS is false
> reclaim and compaction make no progress
> order <= PAGE_ALLOC_COSTLY_ORDER
>
> These conditions happen very often during suspend and resume,
> when pm_restrict_gfp_mask() effectively converts all GFP_KERNEL
> allocations into __GFP_WAIT.
b>
> The oom killer is not run because gfp_mask & __GFP_FS is false,
> but should_alloc_retry will always return true when order is less
> than PAGE_ALLOC_COSTLY_ORDER.
>
> Fix __alloc_pages_slowpath to skip retrying when oom killer is
> not allowed by the GFP flags, the same way it would skip if the
> oom killer was allowed but disabled.
>
> Signed-off-by: Colin Cross <ccross@android.com>
Hi Colin,
Your patch functionally seems fine. I see the problem and we certainly
do not want to have the OOM killer firing during suspend. I would prefer
that the IO devices would not be suspended until reclaim was completed
but I imagine that would be a lot harder.
That said, it will be difficult to remember why checking __GFP_NOFAIL in
this case is necessary and someone might "optimitise" it away later. It
would be preferable if it was self-documenting. Maybe something like
this? (This is totally untested)
mm/page_alloc.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6e8ecb6..ad8f376 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -127,6 +127,20 @@ void pm_restrict_gfp_mask(void)
saved_gfp_mask = gfp_allowed_mask;
gfp_allowed_mask &= ~GFP_IOFS;
}
+
+static bool pm_suspending(void)
+{
+ if ((gfp_allowed_mask & GFP_IOFS) == GFP_IOFS)
+ return false;
+ return true;
+}
+
+#else
+
+static bool pm_suspending(void)
+{
+ return false;
+}
#endif /* CONFIG_PM_SLEEP */
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
@@ -2207,6 +2221,14 @@ rebalance:
goto restart;
}
+
+ /*
+ * Suspend converts GFP_KERNEL to __GFP_WAIT which can
+ * prevent reclaim making forward progress without
+ * invoking OOM. Bail if we are suspending
+ */
+ if (pm_suspending())
+ goto nopage;
}
/* Check if we should retry the allocation */
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-10-25 9:10 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 6:39 [PATCH] mm: avoid livelock on !__GFP_FS allocations Colin Cross
2011-10-25 6:39 ` Colin Cross
2011-10-25 7:40 ` Pekka Enberg
2011-10-25 7:40 ` Pekka Enberg
2011-10-25 7:51 ` Colin Cross
2011-10-25 7:51 ` Colin Cross
2011-10-25 8:08 ` Pekka Enberg
2011-10-25 8:08 ` Pekka Enberg
2011-10-25 22:12 ` David Rientjes
2011-10-25 22:12 ` David Rientjes
2011-10-25 9:09 ` Mel Gorman [this message]
2011-10-25 9:09 ` Mel Gorman
2011-10-25 9:26 ` Colin Cross
2011-10-25 9:26 ` Colin Cross
2011-10-25 11:23 ` Mel Gorman
2011-10-25 11:23 ` Mel Gorman
2011-10-25 17:08 ` Colin Cross
2011-10-25 17:08 ` Colin Cross
2011-11-01 12:28 ` Mel Gorman
2011-11-01 12:28 ` Mel Gorman
2011-10-25 19:39 ` Pekka Enberg
2011-10-25 19:39 ` Pekka Enberg
2011-11-01 12:29 ` Mel Gorman
2011-11-01 12:29 ` Mel Gorman
2011-10-25 19:29 ` Colin Cross
2011-10-25 19:29 ` Colin Cross
2011-10-25 22:18 ` David Rientjes
2011-10-25 22:18 ` David Rientjes
2011-10-26 1:46 ` Colin Cross
2011-10-26 1:46 ` Colin Cross
2011-10-26 5:47 ` David Rientjes
2011-10-26 5:47 ` David Rientjes
2011-10-26 6:12 ` David Rientjes
2011-10-26 6:12 ` David Rientjes
2011-10-26 6:16 ` Colin Cross
2011-10-26 6:16 ` Colin Cross
2011-10-26 6:24 ` David Rientjes
2011-10-26 6:24 ` David Rientjes
2011-10-26 6:26 ` Colin Cross
2011-10-26 6:26 ` Colin Cross
2011-10-26 6:33 ` David Rientjes
2011-10-26 6:33 ` David Rientjes
2011-10-26 6:36 ` Colin Cross
2011-10-26 6:36 ` Colin Cross
2011-10-26 6:51 ` David Rientjes
2011-10-26 6:51 ` David Rientjes
2011-10-26 6:57 ` Colin Cross
2011-10-26 6:57 ` Colin Cross
2011-10-26 7:10 ` David Rientjes
2011-10-26 7:10 ` David Rientjes
2011-10-26 7:22 ` Colin Cross
2011-10-26 7:22 ` Colin Cross
2011-11-01 12:36 ` Mel Gorman
2011-11-01 12:36 ` Mel Gorman
2011-10-25 22:10 ` David Rientjes
2011-10-25 22:10 ` David Rientjes
-- strict thread matches above, loose matches on Subject: below --
2011-11-14 14:04 Mel Gorman
2011-11-14 14:04 ` Mel Gorman
2011-11-14 18:38 ` Andrea Arcangeli
2011-11-14 18:38 ` Andrea Arcangeli
2011-11-15 10:30 ` Mel Gorman
2011-11-15 10:30 ` Mel Gorman
2011-11-14 23:03 ` Andrew Morton
2011-11-14 23:03 ` Andrew Morton
2011-11-15 10:42 ` Mel Gorman
2011-11-15 10:42 ` Mel Gorman
2011-11-15 15:43 ` Mel Gorman
2011-11-15 15:43 ` Mel Gorman
2011-11-15 16:13 ` Minchan Kim
2011-11-15 16:13 ` Minchan Kim
2011-11-15 17:36 ` Mel Gorman
2011-11-15 17:36 ` Mel Gorman
2011-11-16 0:22 ` Minchan Kim
2011-11-16 0:22 ` Minchan Kim
2011-11-16 0:28 ` Colin Cross
2011-11-16 0:28 ` Colin Cross
2011-11-16 0:45 ` Minchan Kim
2011-11-16 0:45 ` Minchan Kim
2011-11-16 7:10 ` Pekka Enberg
2011-11-16 7:10 ` Pekka Enberg
2011-11-16 21:44 ` David Rientjes
2011-11-16 21:44 ` David Rientjes
2011-11-16 21:58 ` Rafael J. Wysocki
2011-11-16 21:58 ` Rafael J. Wysocki
2011-11-16 22:07 ` Minchan Kim
2011-11-16 22:07 ` Minchan Kim
2011-11-16 22:48 ` David Rientjes
2011-11-16 22:48 ` David Rientjes
2011-11-15 21:40 ` David Rientjes
2011-11-15 21:40 ` David Rientjes
2011-11-16 9:52 ` Mel Gorman
2011-11-16 9:52 ` Mel Gorman
2011-11-16 21:39 ` David Rientjes
2011-11-16 21:39 ` David Rientjes
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=20111025090956.GA10797@suse.de \
--to=mgorman@suse.de \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ccross@android.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
/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 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.