From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0 Date: Thu, 10 Jun 2010 15:38:58 -0700 Message-ID: <20100610153858.243201a8.akpm@linux-foundation.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by gabe.freedesktop.org (Postfix) with ESMTP id 3A7989E799 for ; Thu, 10 Jun 2010 15:40:00 -0700 (PDT) In-Reply-To: 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: bugzilla-daemon@bugzilla.kernel.org, devnull@plzk.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.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] [] __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? 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.