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

[Andrew Morton <akpm@linux-foundation.org>]

(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?

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.