From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Akira Yokosawa <akiyks@gmail.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] documentation: Fix two-CPU control-dependency example
Date: Thu, 20 Jul 2017 05:52:19 -0700 [thread overview]
Message-ID: <20170720125219.GO3730@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170720061434.zjjrkkdu7cqkxx6c@tardis>
On Thu, Jul 20, 2017 at 02:14:34PM +0800, Boqun Feng wrote:
> On Wed, Jul 19, 2017 at 10:47:04PM -0700, Paul E. McKenney wrote:
> [...]
> > > Hi Paul,
> > >
> > > I know the compiler could optimize atomics in very interesting ways, but
> > > this case is about volatile, so I guess our case is still fine? ;-)
> >
> > Hello, Boqun,
> >
> > When I asked that question, the answer I got was "the compiler must
> > emit the load instruction, but is under no obligation to actually use the
> > value loaded".
> >
> > I don't happen to like that answer, by the way. ;-)
> >
>
> Me neither, seems to me the kernel happens to work well at
> compiler-optimization's mercy ;-/
>
> With claim like that, compiler could do optimization as turning:
>
> struct task_struct *owner;
>
> for (;;) {
> owner = READ_ONCE(lock->owner);
> if (owner && !mutex_spin_on_owner(lock, owner))
> break;
> /* ... */
>
> into:
>
> struct task_struct *owner;
>
> owner = READ_ONCE(lock->owner);
>
> for (;;READ_ONCE(lock->owner)) {
> if (owner && !mutex_spin_on_owner(lock, owner))
> break;
> /* ... */
>
> Because the load executed in every loop, and they just happen to choose
> not to use the values. And this is within their rights!
Well, this is one reason that I attend standards-committee meetings.
As does Will Deacon. That way, there is someone there to protest when
people argue that the above behavior is just fine. ;-)
Thanx, Paul
> Regards,
> Boqun
>
> > Thanx, Paul
> >
> > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0062r1.html
> > > >
> > >
> > > Great material to wake up mind in the morning! Thanks.
> > >
> > > Regards,
> > > Boqun
> > >
> > > > What are your thoughts on this?
> > > >
> > > > Thanx, Paul
> > > >
> > > > > Thanks, Akira
> > > > >
> > > > > > That said, I very much welcome critical reviews of memory-barriers.txt,
> > > > > > so please do feel free to continue doing that!
> > > > > >
> > > > > > Thanx, Paul
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
next prev parent reply other threads:[~2017-07-20 12:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-17 8:24 [PATCH] documentation: Fix two-CPU control-dependency example Akira Yokosawa
2017-07-19 17:43 ` Paul E. McKenney
2017-07-19 21:33 ` Akira Yokosawa
2017-07-19 21:56 ` Paul E. McKenney
2017-07-20 1:31 ` Boqun Feng
2017-07-20 5:47 ` Paul E. McKenney
2017-07-20 6:14 ` Boqun Feng
2017-07-20 12:52 ` Paul E. McKenney [this message]
2017-07-20 12:55 ` Akira Yokosawa
2017-07-20 16:11 ` Paul E. McKenney
2017-07-20 21:12 ` Akira Yokosawa
2017-07-20 21:42 ` Paul E. McKenney
2017-07-20 22:52 ` Akira Yokosawa
2017-07-20 23:07 ` Paul E. McKenney
2017-07-21 0:24 ` Boqun Feng
2017-07-21 16:31 ` Paul E. McKenney
2017-07-21 23:38 ` Akira Yokosawa
2017-07-23 4:43 ` Paul E. McKenney
2017-07-23 15:39 ` Boqun Feng
2017-07-24 0:04 ` Akira Yokosawa
2017-07-24 4:36 ` Paul E. McKenney
2017-07-24 6:34 ` Boqun Feng
2017-07-24 10:47 ` Akira Yokosawa
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=20170720125219.GO3730@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.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