linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Colin Cross <ccross@android.com>
To: Mel Gorman <mgorman@suse.de>
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 12:29:28 -0700	[thread overview]
Message-ID: <CAMbhsRRhBfJ-e23WHHbGcDUmsgOnbYkJ2uD9AWD4XUaRUu_4_w@mail.gmail.com> (raw)
In-Reply-To: <20111025090956.GA10797@suse.de>

On Tue, Oct 25, 2011 at 2:09 AM, Mel Gorman <mgorman@suse.de> wrote:
> 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 */
>

Your patch solves my immediate problem.
Tested-by: Colin Cross <ccross@android.com>

--
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>

  parent reply	other threads:[~2011-10-25 19:29 UTC|newest]

Thread overview: 47+ 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  7:40 ` Pekka Enberg
2011-10-25  7:51   ` Colin Cross
2011-10-25  8:08     ` Pekka Enberg
2011-10-25 22:12     ` David Rientjes
2011-10-25  9:09 ` Mel Gorman
2011-10-25  9:26   ` Colin Cross
2011-10-25 11:23     ` Mel Gorman
2011-10-25 17:08       ` Colin Cross
2011-11-01 12:28         ` Mel Gorman
2011-10-25 19:39       ` Pekka Enberg
2011-11-01 12:29         ` Mel Gorman
2011-10-25 19:29   ` Colin Cross [this message]
2011-10-25 22:18   ` David Rientjes
2011-10-26  1:46     ` Colin Cross
2011-10-26  5:47       ` David Rientjes
2011-10-26  6:12         ` David Rientjes
2011-10-26  6:16           ` Colin Cross
2011-10-26  6:24             ` David Rientjes
2011-10-26  6:26               ` Colin Cross
2011-10-26  6:33                 ` David Rientjes
2011-10-26  6:36                   ` Colin Cross
2011-10-26  6:51                     ` David Rientjes
2011-10-26  6:57                       ` Colin Cross
2011-10-26  7:10                         ` David Rientjes
2011-10-26  7:22                           ` Colin Cross
2011-11-01 12:36                             ` Mel Gorman
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 18:38 ` Andrea Arcangeli
2011-11-15 10:30   ` Mel Gorman
2011-11-14 23:03 ` Andrew Morton
2011-11-15 10:42   ` Mel Gorman
2011-11-15 15:43     ` Mel Gorman
2011-11-15 16:13 ` Minchan Kim
2011-11-15 17:36   ` Mel Gorman
2011-11-16  0:22     ` Minchan Kim
2011-11-16  0:28       ` Colin Cross
2011-11-16  0:45         ` Minchan Kim
2011-11-16  7:10           ` Pekka Enberg
2011-11-16 21:44             ` David Rientjes
2011-11-16 21:58               ` Rafael J. Wysocki
2011-11-16 22:07               ` Minchan Kim
2011-11-16 22:48                 ` David Rientjes
2011-11-15 21:40 ` David Rientjes
2011-11-16  9:52   ` Mel Gorman
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=CAMbhsRRhBfJ-e23WHHbGcDUmsgOnbYkJ2uD9AWD4XUaRUu_4_w@mail.gmail.com \
    --to=ccross@android.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --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 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).