From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: paulmck@linux.vnet.ibm.com
Cc: Alexander Duyck <alexander.h.duyck@redhat.com>,
linux-arch@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, mathieu.desnoyers@polymtl.ca,
peterz@infradead.org, heiko.carstens@de.ibm.com,
mingo@kernel.org, mikey@neuling.org, linux@arm.linux.org.uk,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
geert@linux-m68k.org, jeffrey.t.kirsher@intel.com,
romieu@fr.zoreil.com, nic_swsd@realtek.com, will.deacon@arm.com,
michael@ellerman.id.au, tony.luck@intel.com,
torvalds@linux-foundation.org, oleg@redhat.com,
schwidefsky@de.ibm.com, fweisbec@gmail.com, davem@davemloft.net
Subject: Re: [PATCH 2/4] arch: Add lightweight memory barriers fast_rmb() and fast_wmb()
Date: Tue, 18 Nov 2014 11:38:03 +1100 [thread overview]
Message-ID: <1416271083.18381.14.camel@kernel.crashing.org> (raw)
In-Reply-To: <20141117201823.GD5050@linux.vnet.ibm.com>
On Mon, 2014-11-17 at 12:18 -0800, Paul E. McKenney wrote:
> On Mon, Nov 17, 2014 at 09:18:13AM -0800, Alexander Duyck wrote:
> > There are a number of situations where the mandatory barriers rmb() and
> > wmb() are used to order memory/memory operations in the device drivers
> > and those barriers are much heavier than they actually need to be. For
> > example in the case of PowerPC wmb() calls the heavy-weight sync
> > instruction when for memory/memory operations all that is really needed is
> > an lsync or eieio instruction.
>
> Is this still the case if one of the memory operations is MMIO? Last
> I knew, it was not.
I *think* (Alexander, correct me if I'm wrong), that what he wants is
the memory<->memory barriers (the smp_* ones) basically for ordering his
loads or stores from/to the DMA area.
The problem is that the smp_* ones aren't compiled for !CONFIG_SMP
IE. Something like:
- Read valid bit from descriptor
- Read rest of descriptor
That needs an rmb of some sort in between, but a full blown "rmb" will
also order vs. MMIOs and end up being a full sync, while an smp_rmb is a
lwsync which is more lightweight.
Similarily:
- Populate descriptor
- Write valid bit
Same deal with wmb ...
Basically, rmb and wmb order both cachable and non-cachable (memory and
MMIO) which makes them needlessly heavy on powerpc and possibly others
when all you need is to order memory accesses to some DMA data
structures. In that case you really want the normal smp_* variants
except they may not be around...
Cheers,
Ben.
next prev parent reply other threads:[~2014-11-18 0:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 17:17 [PATCH 0/4] Add lightweight memory barriers fast_rmb() and fast_wmb() Alexander Duyck
2014-11-17 17:17 ` [PATCH 1/4] arch: Cleanup read_barrier_depends() and comments Alexander Duyck
2014-11-17 17:18 ` [PATCH 2/4] arch: Add lightweight memory barriers fast_rmb() and fast_wmb() Alexander Duyck
2014-11-17 20:04 ` Benjamin Herrenschmidt
2014-11-17 20:24 ` Alexander Duyck
2014-11-18 0:39 ` Benjamin Herrenschmidt
2014-11-18 3:13 ` Alexander Duyck
2014-11-18 11:58 ` Will Deacon
2014-11-18 16:20 ` Alexander Duyck
2014-11-18 16:48 ` Will Deacon
2014-11-18 21:07 ` Benjamin Herrenschmidt
2014-11-17 20:18 ` Paul E. McKenney
2014-11-17 21:11 ` Alexander Duyck
2014-11-17 23:17 ` Paul E. McKenney
2014-11-18 3:33 ` Alexander Duyck
2014-11-18 0:38 ` Benjamin Herrenschmidt [this message]
2014-11-17 20:52 ` Linus Torvalds
2014-11-17 21:54 ` Alexander Duyck
2014-11-18 0:43 ` Benjamin Herrenschmidt
2014-11-18 0:41 ` Benjamin Herrenschmidt
2014-11-17 17:18 ` [PATCH 3/4] r8169: Use fast_rmb() and fast_wmb() for DescOwn checks Alexander Duyck
2014-11-17 17:18 ` [PATCH 4/4] fm10k/igb/ixgbe: Use fast_rmb on Rx descriptor reads Alexander Duyck
2014-11-17 21:32 ` Jeff Kirsher
2014-11-18 9:57 ` [PATCH 0/4] Add lightweight memory barriers fast_rmb() and fast_wmb() David Laight
2014-11-18 15:44 ` Alexander Duyck
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=1416271083.18381.14.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=alexander.h.duyck@redhat.com \
--cc=davem@davemloft.net \
--cc=donald.c.skidmore@intel.com \
--cc=fweisbec@gmail.com \
--cc=geert@linux-m68k.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jeffrey.t.kirsher@intel.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=matthew.vick@intel.com \
--cc=michael@ellerman.id.au \
--cc=mikey@neuling.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=romieu@fr.zoreil.com \
--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;
as well as URLs for NNTP newsgroup(s).