linux-kernel - Re: [patch 21/21] slab defrag: Obsolete SLAB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0805151153440.20201@schroedinger.engr.sgi.com>
Date:	Thu, 15 May 2008 12:09:06 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Matthew Wilcox <matthew@....cx>
cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Andi Kleen <andi@...stfloor.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>, mpm@...enic.com
Subject: Re: [patch 21/21] slab defrag: Obsolete SLAB

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. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/