From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0 Date: Fri, 11 Jun 2010 10:46:07 +0200 Message-ID: <4C11F7CF.6@vmware.com> References: <20100610153858.243201a8.akpm@linux-foundation.org> <1276211748.2220.3.camel@clockmaker-el6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [65.115.85.69]) by gabe.freedesktop.org (Postfix) with ESMTP id 829E09E79D for ; Fri, 11 Jun 2010 01:46:47 -0700 (PDT) In-Reply-To: <1276211748.2220.3.camel@clockmaker-el6> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Dave Airlie Cc: Andrew Morton , "bugzilla-daemon@bugzilla.kernel.org" , "devnull@plzk.org" , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org 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@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] [] __alloc_pages_nodemask+0x5f5/0x6f0 >>> [48126.787716] [] alloc_pages_current+0x95/0x100 >>> [48126.787720] [] new_slab+0x2ba/0x2c0 >>> [48126.787724] [] __slab_alloc+0x14b/0x4e0 >>> [48126.787730] [] ? security_vm_enough_memory_kern+0x21/0x30 >>> [48126.787736] [] ? agp_alloc_page_array+0x5a/0x70 >>> [48126.787740] [] __kmalloc+0x11f/0x1c0 >>> [48126.787744] [] agp_alloc_page_array+0x5a/0x70 >>> [48126.787747] [] agp_generic_alloc_user+0x64/0x140 >>> [48126.787750] [] agp_allocate_memory+0x9a/0x140 >>> [48126.787755] [] drm_agp_allocate_memory+0x9/0x10 >>> [48126.787758] [] drm_agp_bind_pages+0x57/0x100 >>> [48126.787765] [] i915_gem_object_bind_to_gtt+0x144/0x340 >>> [48126.787768] [] i915_gem_object_pin+0xb5/0xd0 >>> [48126.787772] [] i915_gem_do_execbuffer+0x6cc/0x14f0 >>> [48126.787777] [] ? __is_ram+0x0/0x10 >>> [48126.787783] [] ? lookup_memtype+0xce/0xe0 >>> [48126.787787] [] ? i915_gem_execbuffer+0x91/0x390 >>> [48126.787790] [] i915_gem_execbuffer+0x1d5/0x390 >>> [48126.787794] [] ? i915_gem_sw_finish_ioctl+0x90/0xc0 >>> [48126.787799] [] drm_ioctl+0x32a/0x4b0 >>> [48126.787802] [] ? i915_gem_execbuffer+0x0/0x390 >>> [48126.787807] [] vfs_ioctl+0x38/0xd0 >>> [48126.787810] [] do_vfs_ioctl+0x8a/0x580 >>> [48126.787814] [] sys_ioctl+0x81/0xa0 >>> [48126.787820] [] 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