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

[David Rientjes]

On Tue, 9 Jun 2009, Pekka Enberg 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.
> 

I wasn't sure whether you were proposing the patch as an addition to slub 
or just to help with this issue.  I agree it would help in a hopefully 
ratelimited manner for general slab allocation failures and would have 
avoided some of the confusion for this issue from lack of diagnostics.

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

It will lead to false postiives since you can get a free to a full slab 
which moves it back to an allowed node's partial list before count_free() 
is printed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/