Re: Re : .... get_page_from_freelist : MInority Suggestion to acceptGFP_NOFAIL accept during boot

From: David Rientjes
Date: Mon Jul 06 2009 - 23:38:13 EST


On Mon, 6 Jul 2009, Mitchell Erblich wrote:

> David,
>
> The web page http://lkml.indiana.edu/hypermail/linux/kernel/
>
> Looking at the thread of emails on June 24 at 11:07:23
> upcoming kerneloops.org item: get_page_from_freelist
>
> We have code from Arjan de Van
>
> it's this warning in mm/page_alloc.c:
>
> * __GFP_NOFAIL is not to be used in new code.
> *
> * All __GFP_NOFAIL callers should be fixed so that they
> * properly detect and handle allocation failures.
> *
> * We most definitely don't want callers attempting to
> * allocate greater than single-page units with
> * __GFP_NOFAIL.
> */
> WARN_ON_ONCE(order > 0);
>

[ That's actually Andrew's code and comment, which has since been changed
to

WARN_ON_ONCE(order > 1);

by Linus. ]

Your suggestion to revert this "deprecation" doesn't make sense, though,
given the workarounds I mentioned earlier:

> On Jul 3, 2009, at 2:01 AM, David Rientjes wrote:
>
> > I'm confused by your request because all allocations with orders under
> > PAGE_ALLOC_COSTLY_ORDER are inherently __GFP_NOFAIL and those that are not
> > can easily implement the same behavior in the caller:
> >
> > struct page *page;
> > do {
> > page = alloc_pages(...);
> > } while (!page);
> >
> > Hopefully something could be done to ensure the next call to alloc_pages()
> > would be more likely to succeed, but __GFP_NOFAIL doesn't provide that
> > anyway.

That means anything that less than or equal to PAGE_ALLOC_COSTLY_ORDER
(order-3 allocations) will already loop endlessly, regardless of whether
__GFP_NOFAIL is passed to the page allocator or not. Secondly, you can
use my code above to replicate the exact behavior of __GFP_NOFAIL in the
caller.

In other words, the page allocator doesn't need to implement any special
handling for __GFP_NOFAIL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/