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

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/

Relevant Pages

  • Re: [patch 21/21] slab defrag: Obsolete SLAB
    ... when pinning the process to a single processor? ... That program emulates a TPC-C run from the point of view of ... Pinning the process to one ... CPU would miss the point somewhat. ...
    (Linux-Kernel)
  • Re: [patch 21/21] slab defrag: Obsolete SLAB
    ... regressions with tbench, but did you fix the regression with the io-gen ... Pinning the process to one ... CPU would miss the point somewhat. ... performance numbers by pinning the scsi_ram_0 kernel thread to a single ...
    (Linux-Kernel)
  • Re: Automatic updates--MS needs to address performance
    ... Windows products, so the scans take seemingly several times longer than ... We're talking about pinning a CPU for minutes at a time here...enumerating a ...
    (microsoft.public.windowsxp.general)
  • Re: Asf fastforward performance
    ... > thing is when i use dual processor the processor usage is ... If the single processor gives 1, ... smooth yet and the used CPU time will still be near 100%. ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Compaq Proliant 1600 & SMP
    ... CPU: Pentium III/Pentium III Xeon/Celeron ... real memory = 536870912 ... Preloaded elf kernel "kernel" at 0xc03c1000. ... >the OS only seems to be recognizing a single processor. ...
    (freebsd-current)