> From: Frederic Weisbecker <fweis...@gmail.com> > > 2013/10/25 Peter Zijlstra <pet...@infradead.org>: > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/