From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Duyck Subject: Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access Date: Tue, 18 Nov 2014 16:07:59 -0800 Message-ID: <546BDF5F.2040400@redhat.com> References: <20141118172644.26303.37688.stgit@ahduyck-server> <546BCC73.3050903@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "linux-arch@vger.kernel.org" , Network Development , Linux Kernel Mailing List , Mathieu Desnoyers , Peter Zijlstra , Benjamin Herrenschmidt , Heiko Carstens , Ingo Molnar , Michael Neuling , Russell King - ARM Linux , donald.c.skidmore@intel.com, matthew.vick@intel.com, Geert Uytterhoeven , Jeff Kirsher , Francois Romieu , Paul McKenney , nic_swsd@realtek.com, Will Deacon , Michael Ellerman , Tony Luck , Oleg Nesterov , Martin Schwidefsky < To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 11/18/2014 03:06 PM, Linus Torvalds wrote: > On Tue, Nov 18, 2014 at 2:47 PM, Alexander Duyck > wrote: >> >> The problem is DMA is a broad brush. There are multiple cases I can think >> of where DMA does not represent coherent memory. > > .. and I already addressed that, in the thing you even included: > >>> 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). > > The thing is, if the DMA isn't coherent, nobody is going to care about > the memory barriers anyway. You have bigger issues. > > And your argument is that "dma" is bigger than this issue. *MY* > argument is that "coherent" is bigger than this issue. There's tons of > coherent memory that is not about DMA, the same way that there is DMA > memory that isn't coherent. > > See? The two are 100% equivalent. Except "dma" is just three letters, > and matches "smp" both visually and in use (SMP memory is "coherent" > too - yes, you can - and crap architectures do - have incoherent > caches due to virtual aliases etc, but exactly as with DMA, if you > have incoherent SMP, you have bigger issues than the barriers). Actually if anything maybe the crap architectures are a good reason for changing the name. If they can't even do coherent SMP memory then the coherent_*mb() could be misleading since they would just be full barriers anyway. > And yes, you could call it "coherent_dma_read_memory_barrier()", and > it would be very descriptive. It would also drive everybody crazy. No, I think "dma_wmb__before_coherent_write" would have been much more descriptive. You have to squeeze in that extra underscore somewhere. ;-) > So I argue for "dma_mb()" pairing with "smp_mb()" from a naming > standpoint. It just *describes* the problem better. Look at the > drivers, it's very much about the devices doing DMA to memory, and our > ordering. > > To be even more clear: nobody sane cares about the "coherent" part, > because only insane horrible crap architectures have incoherent memory > in the first place, and sane people run away screaming from that > steaming pile of sh*t. I think that is part of my reluctance. I didn't even want it implied that the barriers could be used with that kind of stuff. > Just look at some of the drivers you actually *use* this in. They are > for intel hardware, they presumably would never even work in the first > place without cache-coherent DMA. Why do you think that "coherent" is > so important? > > Linus v5 should be up shortly after a quick pass with sed to do the find/replace, clean up any whitespace issues, and a quick run through some cross compiling scripts just to make sure I didn't screw anything up. - Alex