From: Andrew Theurer <habanero@us.ibm.com>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com,
Xan Charbonnet <xan@charbonnet.com>,
Nicholas Lee <emptysands@gmail.com>
Subject: Re: x86-64 Net Performance
Date: Sun, 09 Oct 2005 10:16:25 -0500 [thread overview]
Message-ID: <43493449.6060906@us.ibm.com> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D32E25F@liverpoolst.ad.cl.cam.ac.uk>
Ian Pratt wrote:
>
>
>
>>Update: I went ahead and compiled glibc without TLS / NPTL.
>>
>>
>
>For 64 bit Xen you don't need to worry about TLS/NPTL.
>
>
>
>>Also, I realized that I wasn't allocating all my physical
>>memory to Domain0 for these tests, so I was giving Xen a
>>disadvantage. It didn't change much, but those tests have
>>been re-done.
>>
>>Here's the odd thing: disabling TLS for 64-bit improved
>>native performance by around 10%, but had no effect on Xen.
>>
>>
>
>How did you disable TLS on 64 bit? It's odd that it would have any
>effect on native or xen, let alone such a dramatic one. Are you sure
>about this test?
>
>
>
>> Native Domain0 Penalty
>>64-bit TLS 50.2 65.0 29.5%
>>64-bit no TLS 44.8 65.0 45.1%
>>32-bit TLS 59.6 59.5 -0.2%
>>32-bit no TLS 59.6 60.2 1.0%
>>
>>
>
>It looks like we need to investigate x86_64 networking performance. We
>may well not be getting the pipelining that we do in 32bit, though I
>can't immediately think why,
>
>
This is a bit surprising as most newer cpus (really any amd_64) has
plenty of processing power, and the Ethernet adapter is almost always
the bottleneck. This was with netperf, but I would not expect a http
get of a single file to be much worse.. I have also seen more overhead
in ia32 than amd_64. Xenoprofile showed (for me) about a 13% cpu
overhead (more than baremetal linux) in amd_64, 3% in xen and about 10%
for the sw bridge. On ia32 (intel xeon) this was about 23%, 13% in xen
and 10% for the bridge. I guess I should run these over again and
check; maybe something have dramatically changed things.
You might want to try this test without starting xend, so the network
bridge is not created and eth0 is put on it. Perhaps that is an issue.
Come to think of it, my tests were not with veth0/vif0.0 -that may
indeed be an issue, going through the front/back-end virtual interfaces,
then on the bridge, then on eth0. I'll kick off some tests tomorrow and
see what I get.
-Andrew
next prev parent reply other threads:[~2005-10-09 15:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-09 9:18 x86-64 Net Performance Ian Pratt
2005-10-09 15:16 ` Andrew Theurer [this message]
2005-10-10 1:52 ` Alexander Charbonnet
2005-10-09 19:47 ` Alexander Charbonnet
-- strict thread matches above, loose matches on Subject: below --
2005-10-08 17:51 Opteron server and NUMA Ian Pratt
2005-10-09 5:46 ` x86-64 Net Performance [was: Opteron server and NUMA] Alexander Charbonnet
2005-10-09 7:33 ` x86-64 Net Performance Xan Charbonnet
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=43493449.6060906@us.ibm.com \
--to=habanero@us.ibm.com \
--cc=emptysands@gmail.com \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=xan@charbonnet.com \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.