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

[Matthew Wilcox]

On Wed, May 14, 2008 at 02:33:11PM -0700, Christoph Lameter wrote:
> On Wed, 14 May 2008, Matthew Wilcox wrote:
> 
> > > No. I thought you were satisfied with the performance increase you saw 
> > > when pinning the process to a single processor?
> > 
> > Er, no.  That program emulates a TPC-C run from the point of view of
> > doing as much IO as possible from all CPUs.  Pinning the process to one
> > CPU would miss the point somewhat.
> 
> Oh. The last message I got was an enthusiatic report on the performance 
> gains you saw by pinning the process after we looked at slub statistics 
> that showed that the behavior of the tests was different from your 
> expectations. I got messages here that indicate that this was a scsi 
> testing program that you had under development. And yes we saw the remote 
> freeing degradations there.

What I said was:

: I've also been playing around with locking the scsi_ram_0 thread to
: one CPU and it has a huge effect on the numbers.

: So we can see that scsi_ram_0 is clearly wandering between the two
: CPUs normally; it takes up a significant (3 seconds ~= 7-8%) of the
: execution time, and that locking it to one CPU (which interrupts tend
: to be) improves the number of ops per second ... even of the CPU which
: is forced to take all the extra work of running it!

Note the complete lack of comparison between slub and slab here!  As far
as I know, slub still loses against slab by a few % -- but I haven't
finished running a comparison with -rc2 yet.

> > I seem to remember telling you that you might get more realistic
> > performance numbers by pinning the scsi_ram_0 kernel thread to a single
> > CPU (ie emulating an interrupt tied to one CPU rather than letting the
> > scheduler choose to run the thread on the 'best' CPU).
> 
> If this is a stand in for the TPC then why did you not point that 
> out when Pekka and I recently asked you to retest some configurations?

I thought you'd already run this test and were asking for the results of
this to be validated against a real TPC run.

I'm rather annoyed by this.  You demand a test-case to reproduce the
problem and then when I come up with one, you ignore it!

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/