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 23:39:19 +0200 Message-ID: <4C12AD07.2030408@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> <4C129B04.6050903@vmware.com> <20100611133754.e1ccd297.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 F2F449E7F1 for ; Fri, 11 Jun 2010 14:39:59 -0700 (PDT) In-Reply-To: <20100611133754.e1ccd297.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 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