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 kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
