Re: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky
Date: Mon Oct 28 2013 - 08:38:45 EST
> From: Frederic Weisbecker <fweisbec@xxxxxxxxx>
>
> 2013/10/25 Peter Zijlstra <peterz@xxxxxxxxxxxxx>:
> > On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
> > I would argue for
> >
> > READ ->data_tail READ ->data_head
> > smp_rmb() (A) smp_rmb() (C)
> > WRITE $data READ $data
> > smp_wmb() (B) smp_mb() (D)
> > STORE ->data_head WRITE ->data_tail
> >
> > Where A pairs with D, and B pairs with C.
> >
> > I don't think A needs to be a full barrier because we won't in fact
> > write data until we see the store from userspace. So we simply don't
> > issue the data WRITE until we observe it.
> >
> > OTOH, D needs to be a full barrier since it separates the data READ
from
> > the tail WRITE.
> >
> > For B a WMB is sufficient since it separates two WRITEs, and for C an
> > RMB is sufficient since it separates two READs.
>
> Hmm, I need to defer on you for that, I'm not yet comfortable with
> picking specific barrier flavours when both write and read are
> involved in a same side :)
I think you have a point :) IMO, memory barrier (A) is superfluous.
At producer side we need to ensure that "WRITE $data" is not committed to
memory
before "READ ->data_tail" had seen a new value and if the old one indicated
that
there is no enough space for a new entry. All this is already guaranteed by
control flow dependancy on single CPU - writes will not be committed to the
memory
if read value of "data_tail" doesn't specify enough free space in the ring
buffer.
Likewise, on consumer side, we can make use of natural data dependency and
memory ordering guarantee for single CPU and try to replace "smp_mb" by
a more light-weight "smp_rmb":
READ ->data_tail READ ->data_head
// ... smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_rmb() (D)
READ $header_size
STORE ->data_head WRITE ->data_tail = $old_data_tail +
$header_size
We ensure that all $data is read before "data_tail" is written by doing
"READ $header_size" after
all other data is read and we rely on natural data dependancy between
"data_tail" write
and "header_size" read.
-- Victor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/