[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B73CC@saturn3.aculab.com>
Date: Thu, 31 Oct 2013 12:28:56 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Victor Kaplansky" <VICTORK@...ibm.com>,
<paulmck@...ux.vnet.ibm.com>
Cc: "Michael Neuling" <mikey@...ling.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@...ymtl.ca>,
"Peter Zijlstra" <peterz@...radead.org>,
"LKML" <linux-kernel@...r.kernel.org>,
"Oleg Nesterov" <oleg@...hat.com>,
"Linux PPC dev" <linuxppc-dev@...abs.org>,
"Anton Blanchard" <anton@...ba.org>,
"Frederic Weisbecker" <fweisbec@...il.com>
Subject: RE: perf events ring buffer memory barrier on powerpc
> "For instance, your producer must issue a "memory barrier" instruction
> after writing the data to shared memory and before inserting it on
> the queue; likewise, your consumer must issue a memory barrier
> instruction after removing an item from the queue and before reading
> from its memory. Otherwise, you risk seeing stale data, since, while
> the Alpha processor does provide coherent memory, it does not provide
> implicit ordering of reads and writes. (That is, the write of the
> producer's data might reach memory after the write of the queue, such
> that the consumer might read the new item from the queue but get the
> previous values from the item's memory."
>
> If yes, I don't think it explains the need of memory barrier on Alpha
> in our case (we all agree about the need of smp_wmb() right before @head
> update by producer). If not, could you please point to specific paragraph?
My understanding is that the extra read barrier the alpha needs isn't to
control the order the cpu performs the memory cycles in, but rather to
wait while the cache system performs all outstanding operations.
So even though the wmb() in the writer ensures the writes are correctly
ordered, the reader can read the old value from the second location from
its local cache.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists