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

[Thomas Hellstrom]

On 06/11/2010 10:37 PM, Andrew Morton wrote:
> On Fri, 11 Jun 2010 22:22:28 +0200
> Thomas Hellstrom<thellstrom at vmware.com>  wrote:
>
>    
>>>>> 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.
>>      
> 128MB total RAM?  Those were the days.
>
> Various page reclaim changes have been made in the past year or so
> which _should_ improve that (eg, lumpy reclaim) but yeah, it's by no
> means a certainty.
>
> The vmalloc fallback hardly hurts anyone.  But it does mean that hardly
> anyone ever executes that codepath, so it won't get tested much.
>
> There was a patch recently which added an API formalising the
> alloc_pages-then-vmalloc fallback approach.  It didn't get merged,
> although there weren't strong feelings either way really.  One benefit
> of that approach is that the alloc/free code itself would get more
> testing coverage, but callers can still screw things up by failing to
> handle vmalloc memory correctly for DMA mapping purposes.
>
> Oh well, where were we?  Remove that __GFP_NORETRY?
>    

Yeah, I think that's the sanest thing to do!

/Thomas