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

David Rientjes
2009-06-09T08:15:25Z

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.