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

[Thomas Hellstrom <thellstrom@vmware.com>]

On 06/11/2010 01:15 AM, Dave Airlie wrote:
> On Thu, 2010-06-10 at 15:38 -0700, Andrew Morton wrote:
>    
>> (switched to email.  Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Mon, 7 Jun 2010 17:32:04 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>      
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>>>
>>>             Summary: page allocation failure. order:1, mode:0x50d0
>>>             Product: Memory Management
>>>             Version: 2.5
>>>      Kernel Version: 2.6.35-rc1
>>>            Platform: All
>>>          OS/Version: Linux
>>>                Tree: Mainline
>>>              Status: NEW
>>>            Severity: normal
>>>            Priority: P1
>>>           Component: Page Allocator
>>>          AssignedTo: akpm@linux-foundation.org
>>>          ReportedBy: devnull@plzk.org
>>>          Regression: No
>>>
>>>
>>> Created an attachment (id=26687)
>>>   -->  (https://bugzilla.kernel.org/attachment.cgi?id=26687)
>>> dmesg
>>>
>>> Never seen this before.
>>>
>>> 2.6.35-rc1 #1 SMP Mon May 31 21:31:02 CEST 2010 x86_64 GNU/Linux
>>>
>>> [48126.787684] Xorg: page allocation failure. order:1, mode:0x50d0
>>> [48126.787691] Pid: 1895, comm: Xorg Tainted: G        W   2.6.35-rc1 #1
>>> [48126.787694] Call Trace:
>>> [48126.787709]  [<ffffffff811192f5>] __alloc_pages_nodemask+0x5f5/0x6f0
>>> [48126.787716]  [<ffffffff81148695>] alloc_pages_current+0x95/0x100
>>> [48126.787720]  [<ffffffff8114e04a>] new_slab+0x2ba/0x2c0
>>> [48126.787724]  [<ffffffff8114ed0b>] __slab_alloc+0x14b/0x4e0
>>> [48126.787730]  [<ffffffff81403f91>] ? security_vm_enough_memory_kern+0x21/0x30
>>> [48126.787736]  [<ffffffff81556e6a>] ? agp_alloc_page_array+0x5a/0x70
>>> [48126.787740]  [<ffffffff8115087f>] __kmalloc+0x11f/0x1c0
>>> [48126.787744]  [<ffffffff81556e6a>] agp_alloc_page_array+0x5a/0x70
>>> [48126.787747]  [<ffffffff81556ee4>] agp_generic_alloc_user+0x64/0x140
>>> [48126.787750]  [<ffffffff8155717a>] agp_allocate_memory+0x9a/0x140
>>> [48126.787755]  [<ffffffff8156c179>] drm_agp_allocate_memory+0x9/0x10
>>> [48126.787758]  [<ffffffff8156c1d7>] drm_agp_bind_pages+0x57/0x100
>>> [48126.787765]  [<ffffffff81627fe4>] i915_gem_object_bind_to_gtt+0x144/0x340
>>> [48126.787768]  [<ffffffff81628295>] i915_gem_object_pin+0xb5/0xd0
>>> [48126.787772]  [<ffffffff81629a4c>] i915_gem_do_execbuffer+0x6cc/0x14f0
>>> [48126.787777]  [<ffffffff81091ba0>] ? __is_ram+0x0/0x10
>>> [48126.787783]  [<ffffffff8106c76e>] ? lookup_memtype+0xce/0xe0
>>> [48126.787787]  [<ffffffff8162ab11>] ? i915_gem_execbuffer+0x91/0x390
>>> [48126.787790]  [<ffffffff8162ac55>] i915_gem_execbuffer+0x1d5/0x390
>>> [48126.787794]  [<ffffffff816255b0>] ? i915_gem_sw_finish_ioctl+0x90/0xc0
>>> [48126.787799]  [<ffffffff81565a0a>] drm_ioctl+0x32a/0x4b0
>>> [48126.787802]  [<ffffffff8162aa80>] ? i915_gem_execbuffer+0x0/0x390
>>> [48126.787807]  [<ffffffff8116c248>] vfs_ioctl+0x38/0xd0
>>> [48126.787810]  [<ffffffff8116c87a>] do_vfs_ioctl+0x8a/0x580
>>> [48126.787814]  [<ffffffff8116cdf1>] sys_ioctl+0x81/0xa0
>>> [48126.787820]  [<ffffffff8103af02>] system_call_fastpath+0x16/0x1b
>>>
>>>        
>> 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.

Now if we still get a "definitive" page allocation failure in this 
codepath, that's not good, but hardly the AGP driver's fault.  Has Intel 
added some kind of accounting for pinned pages yet?


>> Presumably this was added in response to some observed behaviour, but
>> what was it??
>>
>>
>> If the __GFP_NORETRY is indeed useful and legitimate and given that we
>> have a vmalloc fallback, I'd suggest that we add __GFP_NOWARN there as
>> well to keep the bug reports away.
>>
>> btw, agp_memory.vmalloc_flag can be done away with - it's conventional
>> to use is_vmalloc_addr() for this.
>>      
> Lols, conventional my ass, we wanted to add that thing years ago for
> this purpose and got told that would be an insane interface, then the
> same person added the interface a year later and never fixed AGP to use
> it.
>
>    


Indeed. I even recall the phrase "Too ugly to live" :).

> I'll try and write a patch.
>
> Dave.
>
>    
/Thomas