Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access

From: Alexander Duyck
Date: Tue Nov 18 2014 - 17:48:44 EST

On 11/18/2014 12:53 PM, Linus Torvalds wrote:
On Tue, Nov 18, 2014 at 9:28 AM, Alexander Duyck
<alexander.h.duyck@xxxxxxxxxx> wrote:
These patches introduce two new primitives for synchronizing cache coherent
memory writes and reads. These two new primitives are:


So I'm still not convinced about the name. I don't hate it, but if you
ever want to do "read_acquire", then that whole "coherent_" thing does
make for a big mouthful. I don't see why "dma" isn't simpler and more
to the point, and has the advantage of lining up (in documentation
etc) with "smp".

The problem is DMA is a broad brush. There are multiple cases I can think of where DMA does not represent coherent memory.

Why would you ever use "coherent_xyz()" on something that isn't about
dma? If it's cache-coherent memory without DMA, you'd use "smp_xyz()",
so I really do prefer that whole "dma-vs-smp" issue, because it talks
about what is actually the important issue. All sane memory is
coherent, after all (and if it isn't, you have other issues than
memory ordering).


This barrier only applies to a subset of DMA memory types. So yes, "coherent_xyz()" only applies to DMA, but not all DMA memory is coherent as it could be a non-coherent or streaming DMA mapping.

One spot where the name makes sense is in the headers themselves. To avoid duplication of definitions in several spots if CONFIG_SMP was defined I simply defined smp_xyz() as coherent_xyz(). Defining it as dma_xyz() might have made that more difficult to read in terms of what was going on.

- 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
Please read the FAQ at