From: Carlos O'Donell <carlos@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>, libc-alpha <libc-alpha@sourceware.org>
Cc: Florian Weimer <fweimer@redhat.com>
Subject: Commit 27d3ce1467990f89126e228559dec8f84b96c60e?
Date: Tue, 26 Nov 2019 15:01:00 -0000 [thread overview]
Message-ID: <8e209ae2-969e-d4d5-bc00-0111c85198a6@redhat.com> (raw)
HJ,
In commit 27d3ce1467990f89126e228559dec8f84b96c60e we stop
setting bit_arch_Fast_Copy_Backward for Intel Core processors
as an optimization to improve performance.
It turns out that this change also improves performance for
Haswell servers. Was it the intent of this change to *also*
improve performance for Haswell? The comments don't indicate
this and I was worried that it might be an unintentional change
in this case. The particular CPU was a E5-2650 v3.
If we step back and look at the overall sequence of changes and
performance it looks like this:
The performance regression is between this change:
c3d8dc45c9df199b8334599a6cbd98c9950dba62 - Triggers default: handling + TSX handling.
- Causes a 21% lmbench regression for an E5-2650 v3.
and this change (the one we are discussing):
27d3ce1467990f89126e228559dec8f84b96c60e - Removes bit_arch_Fast_Copy_Backward.
- Restores the performance loss.
My worry is that the two are unrelated, and that we've only
just made back performance at the expense of the other change
and we could be doing better.
As our Intel expert what do you think is going on here?
--
Cheers,
Carlos.
[1] https://ark.intel.com/content/www/us/en/ark/products/81705/intel-xeon-processor-e5-2650-v3-25m-cache-2-30-ghz.html
next reply other threads:[~2019-11-26 15:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 15:01 Carlos O'Donell [this message]
2019-12-03 17:43 ` H.J. Lu
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=8e209ae2-969e-d4d5-bc00-0111c85198a6@redhat.com \
--to=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).