From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: barrier: implement wfe-base smp_cond_load_acquire
Date: Fri, 17 Jun 2016 17:04:15 +0100 [thread overview]
Message-ID: <20160617160415.GC1284@arm.com> (raw)
In-Reply-To: <20160617154242.GZ30154@twins.programming.kicks-ass.net>
On Fri, Jun 17, 2016 at 05:42:42PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 17, 2016 at 04:38:03PM +0100, Will Deacon wrote:
> > > Is there any case where we wouldn't want the memory clobber?
> >
> > I don't think you'd need it for cmpwait_relaxed, because the CPU could
> > reorder stuff anyway, so anything the compiler does is potentially futile.
> > So actually, I can respin this without the clobber. I'll simplify
> > the __CMPWAIT_CASE macro to drop the last two parameters as well.
>
> In my previous patches I promoted cmpwait() as a cpu_relax()
> 'replacement'. Should we not retain the compiler barrier semantics
> because of that?
To be honest, it's never been clear to me what purpose the memory clobber
serves in cpu_relax().
> That is, anywhere you use this, you basically _have_ to reread memory,
> because the very fact that you return from this basically indicates its
> been changed.
Sure, but that re-read is likely to be done with an acquire. I think this
boils down to whether or not cmpwait_relaxed has any use-cases outside of
an acquire-based outer-loop like that in smp_cond_load_acquire.
Will
next prev parent reply other threads:[~2016-06-17 16:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 13:12 [PATCH] arm64: barrier: implement wfe-base smp_cond_load_acquire Will Deacon
2016-06-17 14:27 ` Mark Rutland
2016-06-17 15:38 ` Will Deacon
2016-06-17 15:42 ` Mark Rutland
2016-06-17 15:42 ` Peter Zijlstra
2016-06-17 16:04 ` Will Deacon [this message]
2016-06-17 16:14 ` Peter Zijlstra
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=20160617160415.GC1284@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.