From: Grant Grundler <iod00d@hp.com>
To: Roland Dreier <rolandd@cisco.com>
Cc: netdev@vger.kernel.org, openib-general@openib.org
Subject: Re: Timeline of IPoIB performance
Date: Mon, 10 Oct 2005 14:26:52 -0700 [thread overview]
Message-ID: <20051010212652.GG9613@esmail.cup.hp.com> (raw)
In-Reply-To: <521x2tgrim.fsf@cisco.com>
On Mon, Oct 10, 2005 at 11:23:45AM -0700, Roland Dreier wrote:
> > 2.6.12-rc5 in-kernel 1 405 <<<<<
> > 2.6.12-rc4 in-kernel 1 470 <<<<<
>
> I was optimistic when I saw this, because the changeover to git
> occurred with 2.6.12-rc2, so I thought I could use git bisect to track
> down exactly when the performance regression happened.
>
> However, I haven't been able to get numbers that are stable enough to
> track this down. I have two systems, both HP DL145s with dual Opteron
> 875s and two-port mem-free PCI Express HCAs. I use MSI-X with the
> completion interrupt affinity set to CPU 0, and "taskset 2" to run
> netserver and netperf on CPU 1.
As you know, opteron boxes are NUMA. I think you want MSI-X interrupt
bound to the same CPU that's connected to the IO. Is CPU 0 closer to IO?
I would bind netperf to CPU0 and netserver to CPU 1 on each box respectively.
Or just try all 4 combinations to see which combinations are CPU bound
vs memory/IO bound.
> With default netperf parameters (just "-H otherguy") I get numbers
> between ~490 MB/sec and ~550 MB/sec for 2.6.12-rc4 and 2.6.12-rc5.
> The numbers are quite consistent between reboots, but if I reboot the
> system (even keeping the kernel identical), I see large performance
> changes.
I gather you meant "tests" in the first phrase? (vs reboot).
> Presumably something is happening like the cache coloring of
> some hot data structures changing semi-randomly depending on the
> timing of various initialations.
My guess is based on the same premise.
The mem-free card will be very sensitive to were it's control data
is allocated. Is either box configured to interleave memory from
both CPUs?
If it's interleaving, every other cacheline will be "local".
Can you disable interleave and try different netperf/server
bindings as suggested above?
hth,
grant
next prev parent reply other threads:[~2005-10-10 21:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1128672413.13948.326.camel@localhost>
[not found] ` <52br20lsei.fsf@cisco.com>
2005-10-08 2:25 ` Timeline of IPoIB performance Matt Leininger
2005-10-10 18:23 ` Roland Dreier
2005-10-10 20:03 ` Michael S. Tsirkin
2005-10-10 21:03 ` Roland Dreier
2005-10-10 20:17 ` Rick Jones
2005-10-10 20:58 ` Roland Dreier
2005-10-10 21:22 ` Rick Jones
2005-10-10 21:26 ` Grant Grundler [this message]
2005-10-10 23:30 ` Grant Grundler
2005-10-11 0:51 ` Andi Kleen
2005-10-10 23:25 ` Matt Leininger
2005-10-10 23:38 ` Roland Dreier
2005-10-10 23:44 ` Matt Leininger
2005-10-10 23:53 ` Roland Dreier
2005-10-11 4:03 ` Roland Dreier
[not found] <E1EPIxF-0001Cp-00@gondolin.me.apana.org.au>
2005-10-12 16:53 ` Roland Dreier
2005-10-12 18:28 ` Matt Leininger
2005-10-13 1:24 ` Matt Leininger
2005-10-13 1:48 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051010212652.GG9613@esmail.cup.hp.com \
--to=iod00d@hp.com \
--cc=netdev@vger.kernel.org \
--cc=openib-general@openib.org \
--cc=rolandd@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).