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

[Dave Airlie]

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:
> 
> > 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 at linux-foundation.org
> >         ReportedBy: devnull at 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.

> 
> 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.

I'll try and write a patch.

Dave.