[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
On 06/11/2010 10:37 PM, Andrew Morton wrote: > On Fri, 11 Jun 2010 22:22:28 +0200 > Thomas Hellstrom wrote: > > > 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. >>> An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we >>> use them for kernel stacks all the time. I'd say just remove the >>> __GFP_NORETRY and be happy. >>> >>> In fact if the allocations are always this small I'd say we can remove >>> the vmalloc fallback too. However if under some circumstances the >>> allocations can be "large", say order-4 or higher then allocation >>> failures are still a risk. >>> >>> >>> >> Actually, At that time I was working with a SiS GPU (128MiB system), and >> was getting persistent failures for order 1 GFP_KERNEL page allocations >> (albeit not in this codepath). So while they are highly unlikely for >> modern systems, it might be worthwhile keeping the fallback. >> > 128MB total RAM? Those were the days. > > Various page reclaim changes have been made in the past year or so > which _should_ improve that (eg, lumpy reclaim) but yeah, it's by no > means a certainty. > > The vmalloc fallback hardly hurts anyone. But it does mean that hardly > anyone ever executes that codepath, so it won't get tested much. > > There was a patch recently which added an API formalising the > alloc_pages-then-vmalloc fallback approach. It didn't get merged, > although there weren't strong feelings either way really. One benefit > of that approach is that the alloc/free code itself would get more > testing coverage, but callers can still screw things up by failing to > handle vmalloc memory correctly for DMA mapping purposes. > > Oh well, where were we? Remove that __GFP_NORETRY? > Yeah, I think that's the sanest thing to do! /Thomas
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
On 06/11/2010 07:24 PM, Andrew Morton wrote: > On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom > wrote: > > > > 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. >> > An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we > use them for kernel stacks all the time. I'd say just remove the > __GFP_NORETRY and be happy. > > In fact if the allocations are always this small I'd say we can remove > the vmalloc fallback too. However if under some circumstances the > allocations can be "large", say order-4 or higher then allocation > failures are still a risk. > > Actually, At that time I was working with a SiS GPU (128MiB system), and was getting persistent failures for order 1 GFP_KERNEL page allocations (albeit not in this codepath). So while they are highly unlikely for modern systems, it might be worthwhile keeping the fallback. /Thomas
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
On Fri, 11 Jun 2010 22:22:28 +0200 Thomas Hellstrom wrote: > >>> 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. > >> > > An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we > > use them for kernel stacks all the time. I'd say just remove the > > __GFP_NORETRY and be happy. > > > > In fact if the allocations are always this small I'd say we can remove > > the vmalloc fallback too. However if under some circumstances the > > allocations can be "large", say order-4 or higher then allocation > > failures are still a risk. > > > > > > Actually, At that time I was working with a SiS GPU (128MiB system), and > was getting persistent failures for order 1 GFP_KERNEL page allocations > (albeit not in this codepath). So while they are highly unlikely for > modern systems, it might be worthwhile keeping the fallback. 128MB total RAM? Those were the days. Various page reclaim changes have been made in the past year or so which _should_ improve that (eg, lumpy reclaim) but yeah, it's by no means a certainty. The vmalloc fallback hardly hurts anyone. But it does mean that hardly anyone ever executes that codepath, so it won't get tested much. There was a patch recently which added an API formalising the alloc_pages-then-vmalloc fallback approach. It didn't get merged, although there weren't strong feelings either way really. One benefit of that approach is that the alloc/free code itself would get more testing coverage, but callers can still screw things up by failing to handle vmalloc memory correctly for DMA mapping purposes. Oh well, where were we? Remove that __GFP_NORETRY?
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
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 at 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 at linux-foundation.org >>> ReportedBy: devnull at 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: GW 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.78] [] ? __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
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom wrote: > >>> > >>> > >> 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. An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we use them for kernel stacks all the time. I'd say just remove the __GFP_NORETRY and be happy. In fact if the allocations are always this small I'd say we can remove the vmalloc fallback too. However if under some circumstances the allocations can be "large", say order-4 or higher then allocation failures are still a risk.
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
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 at 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 at linux-foundation.org > > ReportedBy: devnull at 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: GW 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.78] [] ? __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. > > 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. I'll try and write a patch. Dave.
Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0
On 06/11/2010 10:37 PM, Andrew Morton wrote: On Fri, 11 Jun 2010 22:22:28 +0200 Thomas Hellstromthellst...@vmware.com wrote: 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. An order-1 GFP_KERNEL allocation is a breeze - slub does them often, we use them for kernel stacks all the time. I'd say just remove the __GFP_NORETRY and be happy. In fact if the allocations are always this small I'd say we can remove the vmalloc fallback too. However if under some circumstances the allocations can be large, say order-4 or higher then allocation failures are still a risk. Actually, At that time I was working with a SiS GPU (128MiB system), and was getting persistent failures for order 1 GFP_KERNEL page allocations (albeit not in this codepath). So while they are highly unlikely for modern systems, it might be worthwhile keeping the fallback. 128MB total RAM? Those were the days. Various page reclaim changes have been made in the past year or so which _should_ improve that (eg, lumpy reclaim) but yeah, it's by no means a certainty. The vmalloc fallback hardly hurts anyone. But it does mean that hardly anyone ever executes that codepath, so it won't get tested much. There was a patch recently which added an API formalising the alloc_pages-then-vmalloc fallback approach. It didn't get merged, although there weren't strong feelings either way really. One benefit of that approach is that the alloc/free code itself would get more testing coverage, but callers can still screw things up by failing to handle vmalloc memory correctly for DMA mapping purposes. Oh well, where were we? Remove that __GFP_NORETRY? Yeah, I think that's the sanest thing to do! /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16148] New: page allocation failure. order:1, mode:0x50d0
(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 at 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 at linux-foundation.org > ReportedBy: devnull at 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: GW 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.78] [] ? __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.
