From: Alan Stern <stern@rowland.harvard.edu>
To: Hernan Luis Ponce de Leon <hernanl.leon@huawei.com>
Cc: Jonas Oberhauser <jonas.oberhauser@huawei.com>,
Boqun Feng <boqun.feng@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
"parri.andrea@gmail.com" <parri.andrea@gmail.com>,
"will@kernel.org" <will@kernel.org>,
"npiggin@gmail.com" <npiggin@gmail.com>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"j.alglave@ucl.ac.uk" <j.alglave@ucl.ac.uk>,
"luc.maranget@inria.fr" <luc.maranget@inria.fr>,
"akiyks@gmail.com" <akiyks@gmail.com>,
"dlustig@nvidia.com" <dlustig@nvidia.com>,
"joel@joelfernandes.org" <joel@joelfernandes.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: "Verifying and Optimizing Compact NUMA-Aware Locks on Weak Memory Models"
Date: Sat, 10 Sep 2022 11:03:30 -0400 [thread overview]
Message-ID: <YxynQmEL6e194Wuw@rowland.harvard.edu> (raw)
In-Reply-To: <b7e32a603fdc4883b87c733f5681c6d9@huawei.com>
On Sat, Sep 10, 2022 at 12:11:36PM +0000, Hernan Luis Ponce de Leon wrote:
>
> What they mean seems to be that a prop relation followed only by wmb
> (not mb) doesn't enforce the order of some writes to the same
> location, leading to the claimed hang in qspinlock (at least as far as
> LKMM is concerned).
You were quoting Jonas here, right? The email doesn't make this obvious
because it doesn't have two levels of "> > " markings.
> What we mean is that wmb does not give the same propagation properties as mb.
In general, _no_ two distinct relations in the LKMM have the same
propagation properties. If wmb always behaved the same way as mb, we
wouldn't use two separate words for them.
> The claim is based on these relations from the memory model
>
> let strong-fence = mb | gp
> ...
> let cumul-fence = [Marked] ; (A-cumul(strong-fence | po-rel) | wmb |
> po-unlock-lock-po) ; [Marked]
> let prop = [Marked] ; (overwrite & ext)? ; cumul-fence* ;
> [Marked] ; rfe? ; [Marked]
Please be more specific. What difference between mb and wmb are you
concerned about? Can you give a small litmus test that illustrates this
difference? Can you explain in more detail how this difference affects
the qspinlock implementation?
> From an engineering perspective, I think the only issue is that cat
> *currently* does not have any syntax for this,
Syntax for what? The difference between wmb and mb?
> nor does herd currently
> implement the await model checking techniques proposed in those works
> (c.f. Theorem 5.3. in the "making weak memory models fair" paper,
> which says that for this kind of loop, iff the mo-maximal reads in
> some graph are read in a loop iteration that does not exit the loop,
> the loop can run forever). However GenMC and I believe also Dat3M and
> recently also Nidhugg support such techniques. It may not even be too
> much effort to implement something like this in herd if desired.
I believe that herd has no way to express the idea of a program running
forever. On the other hand, it's certainly true (in all of these
models) than for any finite number N, there is a feasible execution in
which a loop runs for more than N iterations before the termination
condition eventually becomes true.
Alan
> The Dartagnan model checker uses the Theorem 5.3 from above to detect
> liveness violations.
>
> We did not try to come up with a litmus test about the behavior
> because herd7 cannot reason about liveness.
> However, if anybody is interested, the violating execution is shown here
> https://github.com/huawei-drc/cna-verification/blob/master/verification-output/BUG1.png
>
> Hernan
next prev parent reply other threads:[~2022-09-10 15:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-26 12:48 "Verifying and Optimizing Compact NUMA-Aware Locks on Weak Memory Models" Paul E. McKenney
2022-08-26 16:21 ` Boqun Feng
2022-08-26 16:23 ` Peter Zijlstra
2022-08-26 17:10 ` Alan Stern
2022-08-26 20:42 ` Paul E. McKenney
2022-08-27 16:00 ` Alan Stern
2022-08-27 17:04 ` Paul E. McKenney
2022-09-13 11:24 ` Will Deacon
2022-09-13 12:21 ` Dan Lustig
2022-09-16 8:18 ` Will Deacon
2022-08-26 23:47 ` Peter Zijlstra
2022-08-27 16:05 ` Alan Stern
2022-08-27 16:44 ` Boqun Feng
2022-08-29 2:15 ` Andrea Parri
2022-09-09 11:45 ` Jonas Oberhauser
2022-09-10 12:11 ` Hernan Luis Ponce de Leon
2022-09-10 15:03 ` Alan Stern [this message]
2022-09-10 20:41 ` Hernan Luis Ponce de Leon
2022-09-11 10:20 ` Joel Fernandes
2022-09-12 10:13 ` Jonas Oberhauser
2022-09-12 11:10 ` Hernan Luis Ponce de Leon
2022-09-14 14:41 ` Alan Stern
2022-09-12 12:01 ` Alan Stern
2022-09-11 14:53 ` Andrea Parri
2022-09-12 10:46 ` Jonas Oberhauser
2022-09-12 12:02 ` Alan Stern
2022-08-29 2:33 ` Andrea Parri
2022-08-29 12:25 ` Paul E. McKenney
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=YxynQmEL6e194Wuw@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=hernanl.leon@huawei.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=jonas.oberhauser@huawei.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--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).