All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Charbonnet <alexander@charbonnet.com>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, Nicholas Lee <emptysands@gmail.com>
Subject: Re: x86-64 Net Performance
Date: Sun, 9 Oct 2005 14:47:18 -0500	[thread overview]
Message-ID: <200510091447.19062.alexander@charbonnet.com> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D32E25F@liverpoolst.ad.cl.cam.ac.uk>

I did `apt-get source glibc`, edited debian/sysdeps/amd64.mk to comment out 
the couple of lines enabling NPTL, then used dpkg-buildpackage to generate 
new .debs.

Your skepticism was warranted; I double-checked my changes to that file, and I 
had also disabled a line that set -O3 for the compile.  This seems to account 
for the performance difference on native; recompiling with -O3 intact slows 
things down to normal.  So the conclusion is that NPTL / TLS doesn't make 
much difference.

However, it's kind of odd that disabling -O3 would make things faster on 
native, but have no effect on Xen.

Alex


On Sunday 09 October 2005 04:18 am, 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,
>
> Ian

  parent reply	other threads:[~2005-10-09 19:47 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
2005-10-10  1:52   ` Alexander Charbonnet
2005-10-09 19:47 ` Alexander Charbonnet [this message]
  -- 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=200510091447.19062.alexander@charbonnet.com \
    --to=alexander@charbonnet.com \
    --cc=emptysands@gmail.com \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --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.