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

[David Rientjes]

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/