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 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.