From: Uros Bizjak <ubizjak@gmail.com>
To: David Laight <David.Laight@aculab.com>
Cc: Dave Hansen <dave.hansen@intel.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 <>
Subject: Re: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg
Date: Thu, 6 Apr 2023 10:38:43 +0200 [thread overview]
Message-ID: <CAFULd4YPM18B6Nv=-rNd=D0TmCbn64oLvgbDJ3CWc9DsdJG8gg@mail.gmail.com> (raw)
In-Reply-To: <5c10520ac747430cb421badcb293c706@AcuMS.aculab.com>
On Thu, Apr 6, 2023 at 10:26 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Dave Hansen
> > Sent: 05 April 2023 17:37
> >
> > On 4/5/23 07:17, Uros Bizjak wrote:
> > > Add generic and target specific support for local{,64}_try_cmpxchg
> > > and wire up support for all targets that use local_t infrastructure.
> >
> > I feel like I'm missing some context.
> >
> > What are the actual end user visible effects of this series? Is there a
> > measurable decrease in perf overhead? Why go to all this trouble for
> > perf? Who else will use local_try_cmpxchg()?
>
> I'm assuming the local_xxx operations only have to be save wrt interrupts?
> On x86 it is possible that an alternate instruction sequence
> that doesn't use a locked instruction may actually be faster!
Please note that "local" functions do not use lock prefix. Only atomic
properties of cmpxchg instruction are exploited since it only needs to
be safe wrt interrupts.
Uros.
> Although, maybe, any kind of locked cmpxchg just needs to ensure
> the cache line isn't 'stolen', so apart from possible slight
> delays on another cpu that gets a cache miss for the line in
> all makes little difference.
> The cache line miss costs a lot anyway, line bouncing more
> and is best avoided.
> So is there actually much of a benefit at all?
>
> Clearly the try_cmpxchg help - but that is a different issue.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-04-06 8:38 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 [this message]
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
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='CAFULd4YPM18B6Nv=-rNd=D0TmCbn64oLvgbDJ3CWc9DsdJG8gg@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=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=mattst88@gmail.com \
--cc=richard.henderson@linaro.org \
--cc=tsbogend@alpha.franken.de \
--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).