Messages in this thread | | | Date | Mon, 6 Jul 2009 20:37:51 -0700 (PDT) | From | David Rientjes <> | Subject | Re: Re : .... get_page_from_freelist : MInority Suggestion to accept GFP_NOFAIL accept during boot |
| |
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.
| |