All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Colin Cross <ccross@android.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Rientjes <rientjes@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: avoid livelock on !__GFP_FS allocations
Date: Tue, 15 Nov 2011 10:42:23 +0000	[thread overview]
Message-ID: <20111115104223.GC27150@suse.de> (raw)
In-Reply-To: <20111114150326.0ee60107.akpm@linux-foundation.org>

On Mon, Nov 14, 2011 at 03:03:26PM -0800, Andrew Morton wrote:
> > <SNIP>
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 9dd443d..5402897 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;
> > +}
> 
> This doesn't seem a terribly reliable way of detecting that PM has
> disabled the storage devices (which is what we really want to know
> here: kswapd got crippled).
> 

It only works because PM is the only caller that alters
gfp_allowed_mask at runtime after early boot completes. We also check
if suspend is in progress in mm/swapfile.c#try_to_free_swap() using
the gfp_allowed_mask.

> I guess it's safe for now, because PM is the only caller who alters
> gfp_allowed_mask (I assume). 

You assume correctly.

> But an explicit storage_is_unavaliable
> global which is set and cleared at exactly the correct time is clearer,
> more direct and future-safer, no?
> 

It feels overkill to allocate more global storage for it when
gfp_allowed_mask is already there but I could rename pm_suspending() to
pm_disabled_storage(), make try_to_free_swap() use the same helper but
leave the implementation the same. This would clarify the situation.

> > +#else
> > +
> > +static bool pm_suspending(void)
> > +{
> > +	return false;
> > +}
> >  #endif /* CONFIG_PM_SLEEP */
> >  
> >  #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
> > @@ -2214,6 +2228,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;
> 
> The comment doesn't tell the whole story: it's important that kswapd
> writeout was disabled?
> 

Writeout is disabled for flushers as well but your comment covers both
and clarifies the situation. Thanks

-- 
Mel Gorman
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Colin Cross <ccross@android.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Rientjes <rientjes@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: avoid livelock on !__GFP_FS allocations
Date: Tue, 15 Nov 2011 10:42:23 +0000	[thread overview]
Message-ID: <20111115104223.GC27150@suse.de> (raw)
In-Reply-To: <20111114150326.0ee60107.akpm@linux-foundation.org>

On Mon, Nov 14, 2011 at 03:03:26PM -0800, Andrew Morton wrote:
> > <SNIP>
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 9dd443d..5402897 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;
> > +}
> 
> This doesn't seem a terribly reliable way of detecting that PM has
> disabled the storage devices (which is what we really want to know
> here: kswapd got crippled).
> 

It only works because PM is the only caller that alters
gfp_allowed_mask at runtime after early boot completes. We also check
if suspend is in progress in mm/swapfile.c#try_to_free_swap() using
the gfp_allowed_mask.

> I guess it's safe for now, because PM is the only caller who alters
> gfp_allowed_mask (I assume). 

You assume correctly.

> But an explicit storage_is_unavaliable
> global which is set and cleared at exactly the correct time is clearer,
> more direct and future-safer, no?
> 

It feels overkill to allocate more global storage for it when
gfp_allowed_mask is already there but I could rename pm_suspending() to
pm_disabled_storage(), make try_to_free_swap() use the same helper but
leave the implementation the same. This would clarify the situation.

> > +#else
> > +
> > +static bool pm_suspending(void)
> > +{
> > +	return false;
> > +}
> >  #endif /* CONFIG_PM_SLEEP */
> >  
> >  #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
> > @@ -2214,6 +2228,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;
> 
> The comment doesn't tell the whole story: it's important that kswapd
> writeout was disabled?
> 

Writeout is disabled for flushers as well but your comment covers both
and clarifies the situation. Thanks

-- 
Mel Gorman
SUSE Labs

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

  reply	other threads:[~2011-11-15 10:42 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14 14:04 [PATCH] mm: avoid livelock on !__GFP_FS allocations 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2011-10-25  6:39 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
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

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=20111115104223.GC27150@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=penberg@cs.helsinki.fi \
    --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.