Re: [Bug 16148] New: page allocation failure. order:1, mode:0x50d0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/11/2010 07:24 PM, Andrew Morton wrote:
On Fri, 11 Jun 2010 10:46:07 +0200 Thomas Hellstrom<thellstrom@xxxxxxxxxx>  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

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux