linux-kernel - Re: SLUB performance regression vs 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.0710041156120.11927@schroedinger.engr.sgi.com>
Date:	Thu, 4 Oct 2007 12:05:35 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Matthew Wilcox <willy@...ux.intel.com>
cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Christoph Hellwig <hch@....de>, Mel Gorman <mel@...net.ie>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Chinner <dgc@....com>,
	Jens Axboe <jens.axboe@...cle.com>, suresh.b.siddha@...el.com
Subject: Re: SLUB performance regression vs SLAB

On Thu, 4 Oct 2007, Matthew Wilcox wrote:

> We have three runs, all with 2.6.23-rc3 plus the patches that Suresh
> applied from 20070922.  The first run is with slab.  The second run is
> with SLUB and the third run is SLUB plus the tuning parameters you
> recommended.

There was quite a bit of communication on tuning parameters. Guess we got 
more confusion there and multiple configurations settings that I wanted to 
be tested separately were merged. Setting slub_min_order to more than zero 
can certainly be detrimental to performance since higher order page 
allocations can cause cacheline bouncing on zone locks.

Which patches? 20070922 refers to a pull on the slab git tree on the 
performance branch?

> I have a spreadsheet with Vtune data in it that was collected during
> each of these test runs, so we can see which functions are the hottest.
> I can grab that data and send it to you, if that's interesting.

Please do. Add the kernel .configs please. Is there any slab queue tuning 
going on on boot with the SLAB configuration?

Include any tuning that was done to the kernel please.

> > Was the page allocator pass through patchset 
> > separately applied as I requested?
> 
> I don't believe so.  Suresh?

If it was a git pull then the pass through was included and never taken 
out.

> I think for future tests, it would be easiest if you send me a git
> reference.  That way we will all know precisely what is being tested.

Sure we can do that.

> > Finally: Is there some way that I can reproduce the tests on my machines?
> 
> As usual for these kinds of setups ... take a two-CPU machine, 64GB
> of memory, half a dozen fibre channel adapters, about 3000 discs,
> a commercial database, a team of experts for three months worth of
> tuning ...
> 
> I don't know if anyone's tried to replicate a benchmark like this using
> Postgres.  Would be nice if they have ...

Well we got our own performance test department here at SGI. If we get 
them involved then we can add another 3 months until we get the test 
results confirmed ;-). Seems that this is a small configuration. Why
does it take that long? And the experts knew SLAB and not SLUB right?

Lets look at all the data that you got and then see if this is enough to 
figure out what is wrong.
-
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/