From: Andrea Parri <parri.andrea@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Will Deacon <will.deacon@arm.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"ishkamiel@gmail.com" <ishkamiel@gmail.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
boqun.feng@gmail.com, dhowells@redhat.com, david@fromorbit.com
Subject: Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t
Date: Thu, 16 Nov 2017 11:00:58 +0100 [thread overview]
Message-ID: <20171116100058.GA5625@andrea> (raw)
In-Reply-To: <20171116085804.ixw4x7ssf2ruooqg@hirez.programming.kicks-ass.net>
On Thu, Nov 16, 2017 at 09:58:04AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 10:01:11PM +0100, Andrea Parri wrote:
>
> > > And in specific things like:
> > >
> > > 135e8c9250dd5
> > > ecf7d01c229d1
> > >
> > > which use the release of rq->lock paired with the next acquire of the
> > > same rq->lock to match with an smp_rmb().
> >
> > Those cycles are currently forbidden by LKMM _when_ you consider the
> > smp_mb__after_spinlock() from schedule(). See rfi-rel-acq-is-not-mb
> > from my previous email and Alan's remarks about cumul-fence.
>
> I'm not sure I get your point; and you all seem to forget I do not in
> fact speak the ordering lingo. So I have no idea what
> rfi-blah-blah or cumul-fence mean.
I expand on my comment. Consider the following test:
C T1
{}
P0(int *x, int *y, spinlock_t *s)
{
spin_lock(s);
WRITE_ONCE(*x, 1);
spin_unlock(s);
spin_lock(s);
WRITE_ONCE(*y, 1);
spin_unlock(s);
}
P1(int *x, int *y)
{
int r0;
int r1;
r0 = READ_ONCE(*y);
smp_rmb();
r1 = READ_ONCE(*x);
}
exists (1:r0=1 /\ 1:r1=0)
According to LKMM, the store to x happens before the store to y but there
is no guarantee that the former store propagate (to P1) before the latter
(which is what we need to forbid that state). As a result, that state in
the "exists" clause is _allowed_ by LKMM.
The LKMM encodes happens-before (or execution) ordering with a relation
named "hb", while it encodes "propagation ordering" with "cumul-fence".
Andrea
>
> I know rel-acq isn't smp_mb() and I don't think any of the above patches
> need it to be. They just need it do be a local ordering, no?
>
> Even without smp_mb__after_spinlock() we get that:
>
> spin_lock(&x)
> x = 1
> spin_unlock(&x)
> spin_lock(&x)
> y = 1
> spin_unlock(&x)
>
> guarantees that x happens-before y, right?
>
> And that should be sufficient to then order something else against, like
> for example:
>
> r2 = y
> smp_rmb()
> r1 = x
>
> no?
>
>
next prev parent reply other threads:[~2017-11-16 10:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-23 11:09 [PATCH] refcount: provide same memory ordering guarantees as in atomic_t Elena Reshetova
2017-10-23 13:12 ` Peter Zijlstra
2017-10-27 6:49 ` Reshetova, Elena
2017-10-27 13:56 ` Peter Zijlstra
2017-11-02 11:04 ` Reshetova, Elena
2017-11-02 13:57 ` Peter Zijlstra
2017-11-02 15:40 ` Alan Stern
2017-11-02 16:02 ` Peter Zijlstra
2017-11-02 16:45 ` Peter Zijlstra
2017-11-02 17:08 ` Alan Stern
2017-11-02 17:16 ` Will Deacon
2017-11-02 17:26 ` Peter Zijlstra
2017-11-02 20:21 ` Alan Stern
2017-11-15 18:05 ` Will Deacon
2017-11-15 19:15 ` Alan Stern
2017-11-15 20:03 ` Peter Zijlstra
2017-11-15 20:22 ` Alan Stern
2017-11-16 8:46 ` Peter Zijlstra
2017-11-15 21:01 ` Andrea Parri
2017-11-16 8:58 ` Peter Zijlstra
2017-11-16 10:00 ` Andrea Parri [this message]
2017-11-02 17:45 ` Andrea Parri
2017-11-02 20:28 ` Alan Stern
2017-11-03 11:55 ` Reshetova, Elena
2017-11-13 9:09 ` Reshetova, Elena
2017-11-13 13:19 ` Paul E. McKenney
2017-11-13 16:01 ` Reshetova, Elena
2017-11-13 16:26 ` Paul E. McKenney
2017-11-14 11:23 ` Reshetova, Elena
2017-11-14 17:24 ` Paul E. McKenney
2017-11-16 13:44 ` Michal Hocko
2017-11-16 15:29 ` 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=20171116100058.GA5625@andrea \
--to=parri.andrea@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=elena.reshetova@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ishkamiel@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.