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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx
ReportedBy: devnull@xxxxxxxx
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
