Re: [PATCH 2/4] arch: Add lightweight memory barriers fast_rmb() and fast_wmb()

From: Alexander Duyck
Date: Mon Nov 17 2014 - 16:56:29 EST



On 11/17/2014 12:52 PM, Linus Torvalds wrote:
On Mon, Nov 17, 2014 at 9:18 AM, Alexander Duyck
<alexander.h.duyck@xxxxxxxxxx> 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.
Ugh. I absolutely despise the name.

It's not "fast". It's just limited. It's the same as "smp_*mb()", in
that it works on cacheable memory, but it actually stays around even
for non-SMP builds.

So I think the name is actively misleading.

Naming should be about what it does, not about some kind of PR thing
that confuses people into thinking it's "better".

Maybe "dma_*mb()" would be acceptable, and ends up having the same
naming convention as "smb_*mb()", and explains what it's about.

What would you think of the name "coherent_*mb()"? I would prefer to avoid dma in the name since, at least in my mind, that implies MMIO.

It also ties in well with dma_alloc_coherent/dma_free_coherent which is what would typically be used to allocate the memory we would be using the barrier to protect anyway.

And yes, in the same spirit, it would probably be good to try to
eventually get rid of the plain "*mb()" functions, and perhaps call
them "mmio_*mb()" to clarify that they are about ordering memory wrt
mmio.

Hmm?

Linus

I will work on pulling all of the coherent barrier cases out of using the plain "*mb()" calls first. We need to sort that out before we could look at renaming the plain barrier functions.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/