lkml.org 
[lkml]   [2008]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: GFP_ATOMIC page allocation failures.
This thread seemed to die out with no resolution..

On Thu, Apr 03, 2008 at 12:59:22PM +0400, Evgeniy Polyakov wrote:
> 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.

So this morning, we got a fresh report from this in 2.6.25.6's e1000 driver
https://bugzilla.redhat.com/show_bug.cgi?id=453010
Pages and pages of spew, which make users freak out.
This stuff might be 'nice to know', but if it isn't getting fixed,
I can see why some distros have been shipping the 'silence GFP_ATOMIC failures'
patches for some time.

Dave

> 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.



--
http://www.codemonkey.org.uk


\
 
 \ /
  Last update: 2008-06-26 23:17    [W:2.169 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site