Re: [Bug #13319] Page allocation failures with b43 and p54usb

[Pekka Enberg <penberg@cs.helsinki.fi>]

Hi David,

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> Larry reported this stack trace:
> 
> kernel: git: page allocation failure. order:1, mode:0x4020
> kernel: Pid: 3707, comm: git Not tainted 2.6.30-rc1-wl #115
> kernel: Call Trace:
> kernel:  [<ffffffff80292f84>] __alloc_pages_internal+0x43d/0x45d
> kernel:  [<ffffffff802b2383>] alloc_pages_current+0xbe/0xc6
> kernel:  [<ffffffff802b66a4>] new_slab+0xcf/0x28b
> 
> That's in the order fallback for new slab allocations; so this cache must 
> have oo_order(s->min) of 1.

Yes, agreed which is why I said it's unlikely that the allocated size is
800 bytes or so.

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> To diagnose whether its object size dictates a >0 slab order, you could 
> enable CONFIG_SLUB_STATS (it's disabled in his .config) and check which 
> /sys/kernel/slab/cache/order_fallback increased.  Once you have identified 
> the cache, you can get this information via 
> /sys/kernel/slab/cache/{objsize,order,size}.  I think this is what 
> Christoph was getting at.
> 
> You could even boot with `slub_nomerge' to determine whether cache merging 
> was the issue where the cache under consideration was unnecessarily merged 
> with one that requires larger higher order minimums.

Sure. Applying my diagnostic patch will probably shed some light on the
subject too.

On Tue, 2009-06-09 at 00:54 -0700, David Rientjes wrote:
> I don't quite understand how its necessary to print the partial lists for 
> each node, they should be exhausted if we're allocating a new slab if the 
> node doesn't matter (and can't in Larry's case, he only has one).

It doesn't hurt either, does it? Yes, we expect the partial lists to be
exhausted but it's better to print that out just in case we have a bug
some day somewhere and that condition is not true. This is very
infrequent slow patch code here anyway.

			Pekka