On 06/11/2010 10:37 PM, Andrew Morton wrote: > On Fri, 11 Jun 2010 22:22:28 +0200 > Thomas Hellstrom<thellstrom at 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