[lkml]   [2009]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Bug #13319] Page allocation failures with b43 and p54usb
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.

 \ /
  Last update: 2009-06-09 10:17    [W:0.142 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site