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 22:22:28 +0200 Message-ID: <4C129B04.6050903@vmware.com> References: <20100610153858.243201a8.akpm@linux-foundation.org> <1276211748.2220.3.camel@clockmaker-el6> <4C11F7CF.6@vmware.com> <20100611102417.34a55945.akpm@linux-foundation.org> 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 28D719E8FE for ; Fri, 11 Jun 2010 13:23:09 -0700 (PDT) In-Reply-To: <20100611102417.34a55945.akpm@linux-foundation.org> 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: Andrew Morton Cc: Dave Airlie , "bugzilla-daemon@bugzilla.kernel.org" , "devnull@plzk.org" , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org 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