[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
thellstrom at vmware.com
Fri Jun 11 01:46:07 PDT 2010
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 at bugzilla.kernel.org wrote:
>>> 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 at linux-foundation.org
>>> ReportedBy: devnull at plzk.org
>>> Regression: No
>>> Created an attachment (id=26687)
>>> --> (https://bugzilla.kernel.org/attachment.cgi?id=26687)
>>> 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
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
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
Indeed. I even recall the phrase "Too ugly to live" :).
> I'll try and write a patch.
More information about the dri-devel