From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>,
"alexander.duyck@gmail.com" <alexander.duyck@gmail.com>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michael Neuling <mikey@neuling.org>,
Tony Luck <tony.luck@intel.com>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Oleg Nesterov <oleg@redhat.com>,
Michael Ellerman <michael@ellerman.id.au>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Russell King <linux@arm.linux.org.uk>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] arch: Introduce read_acquire()
Date: Wed, 12 Nov 2014 07:23:22 -0800 [thread overview]
Message-ID: <54637B6A.9070204@redhat.com> (raw)
In-Reply-To: <20141112101532.GJ29390@twins.programming.kicks-ass.net>
On 11/12/2014 02:15 AM, Peter Zijlstra wrote:
> On Tue, Nov 11, 2014 at 01:12:32PM -0800, Alexander Duyck wrote:
>>> Minor nit on naming, but load_acquire would match what we do with barriers,
>>> where you simply drop the smp_ prefix if you want the thing to work on UP
>>> systems too.
>> The problem is this is slightly different, load_acquire in my mind would use
>> a mb() call, I only use a rmb(). That is why I chose read_acquire as the
>> name.
> acquire is not about rmb vs mb, do read up on
> Documentation/memory-barriers.txt. Its a distinctly different semantic.
> Some archs simply lack the means of implementing this semantics and have
> to revert to mb (stronger is always allowed).
>
> Using the read vs load to wreck the acquire semantics is just insane.
Actually I have been reading up on it as I wasn't familiar with C11.
Most of what I was doing was actually based on the documentation in
barriers.txt which was referring to memory operations not loads/stores
when referring to the acquire/release so I assumed the full memory
barrier was required. I wasn't aware that smp_load_acquire was only
supposed to be ordering loads, or that smp_ store_release only applied
to stores.I will probably go back and re-implement this patch as
introducing load_acquire and add store_release as well. I figure it is
possible that a device could be doing something like reading a linked
list in memory ("Example combining sync and lwsync"
http://www.ibm.com/developerworks/systems/articles/powerpc.html#N102B1)
and then you would need both the store_release and the wmb() to deal
with system memory vs system memory ordering, and system memory vs MMIO.
Base drivers have been doing this kind of stuff for a while. The
problem is we have been doing it using barriers that are heavier than
they need to be. For example the reason why I am wanting to shift to
using something like an acquire operation is because the current barrier
we have been using, rmb(), is far heavier than we need for system memory
vs system memory ordering on systems such as PowerPC. What I am looking
for with the load_acquire/store_release is to allow for the use of
lighter weight barriers for updates that only affect system memory.
Thanks,
Alex
next prev parent reply other threads:[~2014-11-12 15:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-11 18:57 [PATCH] arch: Introduce read_acquire() alexander.duyck
2014-11-11 19:40 ` Linus Torvalds
2014-11-11 20:45 ` Alexander Duyck
2014-11-12 10:10 ` Peter Zijlstra
2014-11-12 10:10 ` Will Deacon
2014-11-12 15:42 ` Alexander Duyck
2014-11-11 19:47 ` Will Deacon
2014-11-11 21:12 ` Alexander Duyck
2014-11-12 10:15 ` Peter Zijlstra
2014-11-12 15:23 ` Alexander Duyck [this message]
2014-11-12 15:37 ` Peter Zijlstra
2014-11-12 19:24 ` Alexander Duyck
2014-11-12 20:43 ` David Miller
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=54637B6A.9070204@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=fweisbec@gmail.com \
--cc=geert@linux-m68k.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=michael@ellerman.id.au \
--cc=mikey@neuling.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=schwidefsky@de.ibm.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox