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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>