From: Hernan Luis Ponce de Leon <hernanl.leon@huawei.com>
To: Alan Stern <stern@rowland.harvard.edu>
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 20:41:30 +0000 [thread overview]
Message-ID: <e8b6b7222a894984b4d66cdcc6435efe@huawei.com> (raw)
In-Reply-To: <YxynQmEL6e194Wuw@rowland.harvard.edu>
> You were quoting Jonas here, right? The email doesn't make this obvious
> because it doesn't have two levels of "> > " markings.
Yes, I was quoting Jonas.
It seems my mail client did not format the email correctly and I did not notice.
Sorry for that.
> 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.
I understand that relations with different names are intended to be different.
What I meant was
"wmb gives weaker propagation guarantees than mb and because of this, liveness of qspinlock is not guaranteed in LKMM"
>
> > 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?
Since the code uses wmb, there are certain pairs of events that will not be in strong-fence.
Since strong-fence contributes to cumul-fence, cumul-fence to prop, and prop to hb,
the pair of events related by hb is less that if the code would use mb instead.
Because of this, there are executions (in particular the one that violates liveness) that have
an acyclic hb relation, but would create a cycle (and thus the memory model would not accept
the behavior) if mb would have been used.
> Can you give a small litmus test that illustrates this
> difference? Can you explain in more detail how this difference affects the
> qspinlock implementation?
Here is a litmus test showing the problem (I hope the comment are enough to relate it back to qspinlock)
C Liveness
{
atomic_t x = ATOMIC_INIT(0);
atomic_t y = ATOMIC_INIT(0);
}
P0(atomic_t *x) {
// clear_pending_set_locked
int r0 = atomic_fetch_add(2,x) ;
}
P1(atomic_t *x, int *z) {
// queued_spin_trylock
int r0 = atomic_read(x);
// barrier after the initialization of nodes
smp_wmb();
// xchg_tail
int r1 = atomic_cmpxchg_relaxed(x,r0,42);
// link node into the waitqueue
WRITE_ONCE(*z, 1);
}
P2(atomic_t *x,atomic_t *z) {
// node initialization
WRITE_ONCE(*z, 2);
// queued_spin_trylock
int r0 = atomic_read(x);
// barrier after the initialization of nodes
smp_wmb();
// xchg_tail
int r1 = atomic_cmpxchg_relaxed(x,r0,24);
}
exists (0:r0 = 24 /\ 1:r0 = 26 /\ z=2)
herd7 says that the behavior is observable.
However if you change wmb by mb, it is not observable anymore.
>
> > 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.
Here I was again quoting Jonas.
I think his intention was to make a distinction between graph based semantics and tools.
While herd7 cannot reason about this kind of property, it is possible to define the property
using graph based semantics and there are tools already using this.
Hernan
next prev parent reply other threads:[~2022-09-10 20:41 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
2022-09-10 20:41 ` Hernan Luis Ponce de Leon [this message]
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=e8b6b7222a894984b4d66cdcc6435efe@huawei.com \
--to=hernanl.leon@huawei.com \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.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=stern@rowland.harvard.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