From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Peter Zijlstra <peterz@infradead.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Anvin <hpa@zytor.com>,
Andrea Parri <parri.andrea@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Vince Weaver <vincent.weaver@maine.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>,
Will Deacon <will@kernel.org>,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:locking/core] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire
Date: Wed, 8 Sep 2021 09:08:33 -0700 [thread overview]
Message-ID: <CAHk-=wiXJygbW+_1BdSX6M8j6z4w8gRSHVcaD5saihaNJApnoQ@mail.gmail.com> (raw)
In-Reply-To: <20210908144217.GA603644@rowland.harvard.edu>
On Wed, Sep 8, 2021 at 7:42 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> there is no reason _in theory_ why a CPU shouldn't reorder and interleave
> the operations to get:
I agree about the theory part.
But I think the LKMM should be the strongest ordering that is reasonable.
And it should take common architecture behavior into account.
IOW, if there is some rare architecture where the above can happen,
but no common sane one allows it in practice, we should strive to make
the LKMM the _stronger_ one.
We sure as hell shouldn't say "RISC-V is potentially very weakly
ordered, so we'll allow that weak ordering".
Because overly weak ordering only causes problems for others. And the
performance arguments for it have historically been garbage anyway.
See the pain powerpc goes through because of bad ordering (and even
more so alpha), and see how arm actually strengthened their ordering
to make everybody happier.
So if this is purely a RISC-V thing, then I think it's entirely reasonable to
spin_unlock(&r);
spin_lock(&s);
cannot be reordered.
Strict specifications are not a bad thing, and weak memory ordering is
not inherently good.
Linus
next prev parent reply other threads:[~2021-09-08 16:09 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 18:28 [PATCH memory-model 0/5] Updates to the formal memory model Paul E. McKenney
2018-09-26 18:29 ` [PATCH memory-model 1/5] tools/memory-model: Add litmus-test naming scheme Paul E. McKenney
2018-10-02 10:10 ` [tip:locking/core] " tip-bot for Paul E. McKenney
2018-09-26 18:29 ` [PATCH memory-model 2/5] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire Paul E. McKenney
2018-10-02 10:11 ` [tip:locking/core] " tip-bot for Alan Stern
2021-09-08 11:00 ` Peter Zijlstra
2021-09-08 11:44 ` Peter Zijlstra
2021-09-08 14:42 ` Alan Stern
2021-09-08 15:12 ` Peter Zijlstra
2021-09-08 16:08 ` Linus Torvalds [this message]
2021-09-09 7:25 ` Peter Zijlstra
2021-09-09 13:35 ` Will Deacon
2021-09-09 17:02 ` Linus Torvalds
2021-09-09 18:59 ` Alan Stern
2021-09-09 17:03 ` Dan Lustig
2021-09-09 18:00 ` Paul E. McKenney
2021-09-10 14:20 ` Boqun Feng
2021-09-10 15:33 ` Palmer Dabbelt
2021-09-10 16:36 ` Alan Stern
2021-09-10 17:12 ` Peter Zijlstra
2021-09-10 17:56 ` Alan Stern
2021-09-10 17:17 ` Peter Zijlstra
2021-09-12 0:26 ` Boqun Feng
2021-09-10 0:01 ` Boqun Feng
2021-09-10 5:37 ` Boqun Feng
2021-09-10 9:33 ` Peter Zijlstra
2021-09-10 10:04 ` Boqun Feng
2021-09-10 13:48 ` Dan Lustig
2021-09-10 14:15 ` Boqun Feng
2021-09-09 17:46 ` Paul E. McKenney
2021-09-10 11:08 ` Will Deacon
2021-09-17 3:21 ` Nicholas Piggin
2021-09-17 5:31 ` Nicholas Piggin
2021-09-17 14:36 ` Michael Ellerman
2018-09-26 18:29 ` [PATCH memory-model 3/5] tools/memory-model: Fix a README typo Paul E. McKenney
2018-10-02 10:11 ` [tip:locking/core] " tip-bot for SeongJae Park
2018-09-26 18:29 ` [PATCH memory-model 4/5] tools/memory-model: Add more LKMM limitations Paul E. McKenney
2018-10-02 10:12 ` [tip:locking/core] " tip-bot for Paul E. McKenney
2018-09-26 18:29 ` [PATCH memory-model 5/5] doc: Replace smp_cond_acquire() with smp_cond_load_acquire() Paul E. McKenney
2018-10-02 10:12 ` [tip:locking/core] locking/memory-barriers: " tip-bot for Andrea Parri
2018-10-02 8:28 ` [PATCH memory-model 0/5] Updates to the formal memory model Ingo Molnar
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='CAHk-=wiXJygbW+_1BdSX6M8j6z4w8gRSHVcaD5saihaNJApnoQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=acme@redhat.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=vincent.weaver@maine.edu \
--cc=will@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 NNTP newsgroup(s).