Re: GFP_ATOMIC page allocation failures.

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Thursday 03 April 2008 02:54, Andrew Morton wrote:
> On Wed, 2 Apr 2008 20:12:58 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 
wrote:
> > On Wednesday 02 April 2008 18:56, Andrew Morton wrote:
> > > > Limiting this to once per boot should suffice for debugging purposes.
> > > > Even if you manage to concoct a bug that always survives the first
> > > > failure, you should be able to take the hint when you keep seeing
> > > > this in dmesg.
> > >
> > > The appropriate thing to do here is to convert known-good drivers (such
> > > as e1000[e]) to use __GFP_NOWARN.
> > >
> > > Unfortunately netdev_alloc_skb() went and assumed GFP_ATOMIC, but I
> > > guess we can dive below the covers and use __netdev_alloc_skb():
> >
> > It's still actually nice to know how often it is happening even for
> > these known good sites because too much can indicate a problem and
> > that you could actually bring performance up by tuning some things.
>
> Yes, it's useful debugging.  It tells us when we mucked up the page
> allocator.

Right.


> It also tells us when we mucked up the net driver - I doubt if we (or at
> least, I) would have discovered that e1000 does a 32k allocation for a
> 5k(?) frame if this warning wasn't coming out.

Is that right? If it is allocating for 9K MTU, then the slab allocator
(slub in this case) will bump that up to the 16K kmalloc slab. If it is
a 5K frame, then it would get the 8K kmalloc slab I think.

Oh, but SLUB's default MIN_OBJECTS is 4, so 4*8 is 32 indeed. So slub
is probably deciding to round the kmalloc-8192 allocations up to order-3.
I think. How did you know it was a 5k frame? :)