From: Will Deacon <will.deacon@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Stafford Horne <shorne@gmail.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
David Howells <dhowells@redhat.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: asm-generic: Disallow no-op mb() for SMP systems
Date: Thu, 1 Feb 2018 13:32:30 +0000 [thread overview]
Message-ID: <20180201133229.GB9182@arm.com> (raw)
In-Reply-To: <20180201132909.GW2249@hirez.programming.kicks-ass.net>
On Thu, Feb 01, 2018 at 02:29:09PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 01, 2018 at 09:27:50PM +0900, Stafford Horne wrote:
> > I tried to clarify some of this in the spec v1.2 [0] which help formalize some of
> > the techniques we used for the SMP implementation. Its probably not perfect,
> > but I added a section "10. Multicore support" and tried to clarify some things
> > in section 7 on Atomicity. But it seems I dont cover exactly what are are
> > mentioning here. In general:
> >
> > 1 Secondary cores have memory snooping enabled meaning that any write to a
> > cached address will cause the cache line to be invalidated.
> > 2 l.swa (store atomic word) implies a store buffer flush.
>
> What about l.lwa? Can that observe 'old' values, or rather, miss values
> stuck in a remote store buffer?
>
> This will then cause the first l.swa to fail, which, per the above,
> would then sync things up? Which means you get that one extra
> merry-go-round.
That's ok from a correctness perspective, though, as long as store buffers
are guaranteed to drain.
> > 3 l.msync is used to flush the store buffer
> >
> > Also, during the IPI controller review [1] Marc Z asked many similar questions.
> > I believe he was ok in the end.
> >
> > Anyway,
> > Thanks for thanks for spotting the issue here. For some reason I remember we
> > did have an l.msync for our mb(). Let me think about and test out this patch
> > (and the fix to actually define mb) to see if anything comes up.
> >
> > Also, I haven't seen any implementations that use WOM. Stefan might know better.
>
> So if the strong model has a store buffer, as I think the above says,
> then it is _NOT_ correct for l.msync to be treated as a NOP, it _must_
> flush the store buffer.
>
> At which point I think your 'strong' model is basically TSO. So it would
> be very good to get that spelled out somewhere.
Agreed, especially as a software person reading the spec may end up thinking
that they don't need to use l.msync if they never set WOM. At least, I read
it this way despite knowing that it's probably not what you intended.
Will
next prev parent reply other threads:[~2018-02-01 13:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 13:00 asm-generic: Disallow no-op mb() for SMP systems Peter Zijlstra
2018-01-31 13:17 ` Will Deacon
2018-01-31 13:26 ` Peter Zijlstra
2018-02-01 12:27 ` Stafford Horne
2018-02-01 13:29 ` Peter Zijlstra
2018-02-01 13:32 ` Will Deacon [this message]
2018-02-01 13:53 ` Peter Zijlstra
2018-02-01 15:39 ` Will Deacon
2018-02-01 15:50 ` Peter Zijlstra
2018-02-01 15:52 ` Peter Zijlstra
2018-02-02 13:48 ` Stafford Horne
2018-02-02 19:14 ` kbuild test robot
2018-02-03 11:43 ` Peter Zijlstra
2018-02-02 20:00 ` kbuild test robot
2018-02-02 20:25 ` Peter Zijlstra
2018-02-02 21:08 ` Alan Cox
2018-02-03 11:42 ` 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=20180201133229.GB9182@arm.com \
--to=will.deacon@arm.com \
--cc=arnd@arndb.de \
--cc=dhowells@redhat.com \
--cc=jonas@southpole.se \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=shorne@gmail.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=tglx@linutronix.de \
/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.