Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Thomas Hellstrom <thellstrom@vmware.com>]

On 06/11/2010 07:24 PM, Andrew Morton wrote:
> On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom<thellstrom@vmware.com>  wrote:
>
>    
>>>>>
>>>>>            
>>>> David, I have a vague feeling that we've been round this loop before..
>>>>
>>>> Why does agp_alloc_page_array() use __GFP_NORETRY?  It's pretty unusual
>>>> and it's what caused this spew.
>>>>
>>>> There's nothing in the changelog and the only relevant commentary
>>>> appears to be "This speeds things up and also saves memory for small
>>>> AGP regions", which is inscrutable.  Can you please add a usable
>>>> comment there?
>>>>
>>>>          
>>> cc'ing Thomas, who added this, I expect we could drop the NORETRY or
>>> just add NOWARN. Though an order 1 page alloc failure isn't a pretty
>>> sight, not sure how a vmalloc fallback could save us.
>>>
>>>
>>>        
>> Hmm. IIRC that was an untested speed optimization back from the time
>> when I was
>> reading ldd3. I think the idea was to avoid slow allocations of (order>
>> 0) if they weren't
>> immediately available and fall back to vmalloc single page allocations.
>> It might be that that functionality is no longer preserved and only the
>> __GFP_NORETRY remains.
>> I think it should be safe to remove the NORETRY if it's annoying, but it
>> should probably be equally safe to add a NOWARN and keep the vmalloc
>> fallback.
>>      
> An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we
> use them for kernel stacks all the time.  I'd say just remove the
> __GFP_NORETRY and be happy.
>
> In fact if the allocations are always this small I'd say we can remove
> the vmalloc fallback too.  However if under some circumstances the
> allocations can be "large", say order-4 or higher then allocation
> failures are still a risk.
>
>    

Actually, At that time I was working with a SiS GPU (128MiB system), and 
was getting persistent failures for order 1 GFP_KERNEL page allocations 
(albeit not in this codepath). So while they are highly unlikely for 
modern systems, it might be worthwhile keeping the fallback.

/Thomas