Thread (32 messages) 32 messages, 10 authors, 2019-01-20

Re: [PATCH RFC 3/4] barriers: convert a control to a data dependency

From: Peter Zijlstra <peterz@infradead.org>
Date: 2019-01-07 15:54:44
Also in: linux-alpha, linux-arch, linux-doc, lkml, virtualization

On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
quoted
How about naming the thing: dependent_ptr() ? That is without any (r)mb
implications at all. The address dependency is strictly weaker than an
rmb in that it will only order the two loads in qestion and not, like
rmb, any prior to any later load.
So I'm fine with this as it's enough for virtio, but I would like to point out two things:

1. E.g. on x86 both SMP and DMA variants can be NOPs but
the madatory one can't, so assuming we do not want
it to be stronger than rmp then either we want
smp_dependent_ptr(), dma_dependent_ptr(), dependent_ptr()
or we just will specify that dependent_ptr() works for
both DMA and SMP.
The latter; the construct simply generates dependent loads. It is up to
the CPU as to what all that works for.
2. Down the road, someone might want to order a store after a load.
Address dependency does that for us too. Assuming we make
dependent_ptr a NOP on x86, we will want an mb variant
which isn't a NOP on x86. Will we want to rename
dependent_ptr to dependent_ptr_rmb at that point?
Not sure; what is the actual overhead of the construct on x86 vs the
NOP?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help