On 06/11/2010 10:37 PM, Andrew Morton wrote:
On Fri, 11 Jun 2010 22:22:28 +0200
Thomas Hellstrom<thellstrom@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
