Re: GFP_ATOMIC page allocation failures.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Wed, Apr 02, 2008 at 10:32:54PM -0700, Andrew Morton (akpm@linux-foundation.org) wrote:
> > > 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? :)
> 
> urgh, it was a while ago, and I don't know if e1000e retains the behaviour.
> 
> iirc the issue was with some errant versions of the hardware needing
> exorbitant alignment and additional padding at the end because of
> occasional DMA overruns.  Something like that.

e1000 hardware does require power-of-two alignment, network stack adds
additional structure at the end, so with e1000 it ends up with two
rounds to the higher power of two.
5k ends up with 16k allocations, 9k - to 32k.

This problem is known for years already and number of fixes was
proposed, but the really good one is to rewrite e1000 allocation path to
use fragments, which I believe was done in the new e1000 driver.

And as a side note: shuting allocation failures is a very bad step,
since it hides allocation problems for drivers. if people do care about
it add __GFP_SMALL_WARN flag which will just print that allocation
failed, its order and function where it happend.

-- 
	Evgeniy Polyakov