(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: NoCreated 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.