lkml.org 
[lkml]   [2014]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access
On 11/18/2014 12:53 PM, Linus Torvalds wrote:
> On Tue, Nov 18, 2014 at 9:28 AM, Alexander Duyck
> <alexander.h.duyck@redhat.com> wrote:
>> These patches introduce two new primitives for synchronizing cache coherent
>> memory writes and reads. These two new primitives are:
>>
>> coherent_rmb()
>> coherent_wmb()
>
> 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).
>
> Linus

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


\
 
 \ /
  Last update: 2014-11-19 00:01    [W:0.068 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site