From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Peter Zijlstra <peterz@infradead.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Michael Neuling <mikey@neuling.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
Geert Uytterhoeven <geert@linux-m68k.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Francois Romieu <romieu@fr.zoreil.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
nic_swsd@realtek.com, Will Deacon <will.deacon@arm.com>,
Michael Ellerman <michael@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access
Date: Tue, 18 Nov 2014 16:07:59 -0800 [thread overview]
Message-ID: <546BDF5F.2040400@redhat.com> (raw)
In-Reply-To: <CA+55aFwHUQv+zBxyN41Y4MDyRXbQ84H8zc01O6O_eg9ZvoqYiQ@mail.gmail.com>
On 11/18/2014 03:06 PM, Linus Torvalds wrote:
> On Tue, Nov 18, 2014 at 2:47 PM, Alexander Duyck
> <alexander.h.duyck@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"Network Development" <netdev@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>,
"Peter Zijlstra" <peterz@infradead.org>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Heiko Carstens" <heiko.carstens@de.ibm.com>,
"Ingo Molnar" <mingo@kernel.org>,
"Michael Neuling" <mikey@neuling.org>,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"Jeff Kirsher" <jeffrey.t.kirsher@intel.com>,
"Francois Romieu" <romieu@fr.zoreil.com>,
"Paul McKenney" <paulmck@linux.vnet.ibm.com>,
nic_swsd@realtek.com, "Will Deacon" <will.deacon@arm.com>,
"Michael Ellerman" <michael@ellerman.id.au>,
"Tony Luck" <tony.luck@intel.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"David Miller" <davem@davemloft.net>
Subject: Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access
Date: Tue, 18 Nov 2014 16:07:59 -0800 [thread overview]
Message-ID: <546BDF5F.2040400@redhat.com> (raw)
Message-ID: <20141119000759.XTn5TnDOIA7u-caijbOhvXim5TiRapxrffXdiJDVYtA@z> (raw)
In-Reply-To: <CA+55aFwHUQv+zBxyN41Y4MDyRXbQ84H8zc01O6O_eg9ZvoqYiQ@mail.gmail.com>
On 11/18/2014 03:06 PM, Linus Torvalds wrote:
> On Tue, Nov 18, 2014 at 2:47 PM, Alexander Duyck
> <alexander.h.duyck@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Peter Zijlstra <peterz@infradead.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Michael Neuling <mikey@neuling.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
Geert Uytterhoeven <geert@linux-m68k.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Francois Romieu <romieu@fr.zoreil.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
nic_swsd@realtek.com, Will Deacon <will.deacon@arm.com>,
Michael Ellerman <michael@ellerman.id.au>,
Tony Luck <tony.luck@intel.com>, Oleg Nesterov <oleg@redhat.com>,
Martin Schwidefsky <
Subject: Re: [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access
Date: Tue, 18 Nov 2014 16:07:59 -0800 [thread overview]
Message-ID: <546BDF5F.2040400@redhat.com> (raw)
In-Reply-To: <CA+55aFwHUQv+zBxyN41Y4MDyRXbQ84H8zc01O6O_eg9ZvoqYiQ@mail.gmail.com>
On 11/18/2014 03:06 PM, Linus Torvalds wrote:
> On Tue, Nov 18, 2014 at 2:47 PM, Alexander Duyck
> <alexander.h.duyck@redhat.com> 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
next prev parent reply other threads:[~2014-11-19 0:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 17:28 [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access Alexander Duyck
2014-11-18 17:29 ` [PATCH v4 1/4] arch: Cleanup read_barrier_depends() and comments Alexander Duyck
2014-11-18 17:29 ` [PATCH v4 2/4] arch: Add lightweight memory barriers coherent_rmb() and coherent_wmb() Alexander Duyck
2014-11-18 17:29 ` [PATCH v4 3/4] r8169: Use coherent_rmb() and coherent_wmb() for DescOwn checks Alexander Duyck
2014-11-18 17:29 ` [PATCH v4 4/4] fm10k/igb/ixgbe: Use coherent_rmb on Rx descriptor reads Alexander Duyck
2014-11-18 20:53 ` [PATCH v4 0/4] Add lightweight memory barriers for coherent memory access Linus Torvalds
2014-11-18 20:53 ` Linus Torvalds
2014-11-18 20:53 ` Linus Torvalds
2014-11-18 22:47 ` Alexander Duyck
2014-11-18 22:47 ` Alexander Duyck
2014-11-18 22:47 ` Alexander Duyck
2014-11-18 23:06 ` Linus Torvalds
2014-11-18 23:06 ` Linus Torvalds
2014-11-18 23:06 ` Linus Torvalds
2014-11-19 0:07 ` Alexander Duyck [this message]
2014-11-19 0:07 ` Alexander Duyck
2014-11-19 0:07 ` 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=546BDF5F.2040400@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=donald.c.skidmore@intel.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.