Re: [patch 21/21] slab defrag: Obsolete SLAB

Christoph Lameter
2008-05-15T19:09:29Z

On Thu, 15 May 2008, Matthew Wilcox wrote:

> Or possibly your assumptions have been the main factor. I gave you a
> reproducer for this problem 6 weeks ago. As far as I can tell, you
> haven't run it since.

Assumptions may be the issue. My own "reproducer" for remote frees is
available from my git tree and I usually prefer to run my own. We
discussed the results of that program last fall. You stated yesterday that
your code is proprietary. I am not sure what I am allowed to do with the
code. I did not know that it was proprietary before yesterday and I would
have just forwarded that code to Pekka yesterday if I would not have
caught that message in time.

I thought that what you provided it was a test program to exercise
and optimize the scsi subsystem?

> > > > You could just start with 2.6.25.X which already contains the slab
> > > > statistics.
> > >
> > > Certainly. Exactly how does collecting these stats work? Am I supposed
> > > to zero the counters after the TPC has done its initial ramp-up? What
> > > commands should I run, and at exactly which points?
> >
> > Compile slabinfo and then do f.e. slabinfo -AD (this is documented in the
> > help text provided when enabling statistics).
>
> That's an utterly unhelpful answer. Let me try asking again.
>
> Exactly how does collecting these stats work? Am I supposed to zero
> the counters after the TPC has done its initial ramp-up? What commands
> should I run, and at exactly which points?

There is no way of zeroing the counters. Run slabinfo -AD after the
test application has been running for awhile. If you want a differential
then you have to take two datapoints.

> Otherwise I'll get something wrong and these numbers will be useless to
> you. Or that's what you'll claim anyway.

No. I guess I will end up with a lot of guess work of what is going on on
the system since the information is limited for some reason.

> For reference the helptext says:
>
> SLUB statistics are useful to debug SLUBs allocation behavior in
> order find ways to optimize the allocator. This should never be
> enabled for production use since keeping statistics slows down
> the allocator by a few percentage points. The slabinfo command
> supports the determination of the most active slabs to figure
> out which slabs are relevant to a particular load.
> Try running: slabinfo -DA
>
> By the way, when you say 'compile slabinfo', you mean the file shipped
> as Documentation/vm/slabinfo.c (rather than, say, something out of tree?)

Yes.