From: David Laight <David.Laight@ACULAB.COM>
To: 'Dave Hansen' <dave.hansen@intel.com>,
Mark Rutland <mark.rutland@arm.com>
Cc: Uros Bizjak <ubizjak@gmail.com>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Michael Ellerman <mpe@el>
Subject: RE: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg
Date: Tue, 11 Apr 2023 21:34:35 +0000 [thread overview]
Message-ID: <bd5753622f2f42248495a42593b497f3@AcuMS.aculab.com> (raw)
In-Reply-To: <1fee0372-3a3b-5e09-38c3-ffb3523fe195@intel.com>
From: Dave Hansen
> Sent: 11 April 2023 14:44
>
> On 4/11/23 04:35, Mark Rutland wrote:
> > I agree it'd be nice to have performance figures, but I think those would only
> > need to demonstrate a lack of a regression rather than a performance
> > improvement, and I think it's fairly clear from eyeballing the generated
> > instructions that a regression isn't likely.
>
> Thanks for the additional context.
>
> I totally agree that there's zero burden here to show a performance
> increase. If anyone can think of a quick way to do _some_ kind of
> benchmark on the code being changed and just show that it's free of
> brown paper bags, it would be appreciated. Nothing crazy, just think of
> one workload (synthetic or not) that will stress the paths being changed
> and run it with and without these changes. Make sure there are not
> surprises.
>
> I also agree that it's unlikely to be brown paper bag material.
The only thing I can think of is that, on x86, the locked
variant may actually be faster!
Both require exclusive access to the cache line (the unlocked
variant always does the write! [1]).
So if the cache line is contended between cpu the unlocked
variant might ping-pong the cache line twice!
Of course, if the line is shared like that then performance
is horrid.
[1] I checked on an uncached PCIe address on which I can monitor
the TLP. The write always happens so you can use cmpxchg18b
with a 'known bad value' to do a 16 byte read as a single TLP
(without using an SSE register).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2023-04-11 21:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 14:17 [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg Uros Bizjak
2023-04-05 14:17 ` [PATCH v2 1/5] locking/atomic: Add generic try_cmpxchg{,64}_local support Uros Bizjak
2023-04-11 11:10 ` Mark Rutland
2023-04-05 14:17 ` [PATCH v2 2/5] locking/generic: Wire up local{,64}_try_cmpxchg Uros Bizjak
2023-04-11 11:13 ` Mark Rutland
2023-04-05 14:17 ` [PATCH v2 3/5] locking/arch: Wire up local_try_cmpxchg Uros Bizjak
2023-04-12 11:32 ` Peter Zijlstra
2023-04-12 13:37 ` Uros Bizjak
2023-04-12 13:40 ` Peter Zijlstra
2023-05-17 7:41 ` Charlemagne Lasse
2023-04-05 14:17 ` [PATCH v2 4/5] locking/x86: Define arch_try_cmpxchg_local Uros Bizjak
2023-04-05 14:17 ` [PATCH v2 5/5] events: Illustrate the transition to local{,64}_try_cmpxchg Uros Bizjak
2023-04-05 16:37 ` [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg Dave Hansen
2023-04-05 18:53 ` Uros Bizjak
2023-04-06 8:25 ` David Laight
2023-04-06 8:38 ` Uros Bizjak
2023-04-06 9:01 ` David Laight
2023-04-11 11:35 ` Mark Rutland
2023-04-11 13:43 ` Dave Hansen
2023-04-11 21:34 ` David Laight [this message]
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=bd5753622f2f42248495a42593b497f3@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@intel.com \
--cc=ink@jurassic.park.msu.ru \
--cc=kernel@xen0n.name \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mattst88@gmail.com \
--cc=mpe@el \
--cc=richard.henderson@linaro.org \
--cc=tsbogend@alpha.franken.de \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.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).