Re: perf events ring buffer memory barrier on powerpc

From: Victor Kaplansky
Date: Fri Nov 01 2013 - 09:13:15 EST

"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote on 10/31/2013
08:16:02 AM:

> > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > around
> > @head read.

Just to be sure, that we are talking about the same code - I was
ACCESS_ONCE() around @tail in point AAA in the following example from
Documentation/circular-buffers.txt for CONSUMER:

unsigned long head = ACCESS_ONCE(buffer->head);
unsigned long tail = buffer->tail; /* AAA */

if (CIRC_CNT(head, tail, buffer->size) >= 1) {
/* read index before reading contents at that index */

/* extract one item from the buffer */
struct item *item = buffer[tail];


smp_mb(); /* finish reading descriptor before incrementing
tail */

buffer->tail = (tail + 1) & (buffer->size - 1); /* BBB */

> If you omit the ACCESS_ONCE() calls around @tail, the compiler is within
> its rights to combine adjacent operations and also to invent loads and
> stores, for example, in cases of register pressure.

Right. And I was completely aware about these possible transformations when
said that ACCESS_ONCE() around @tail in point AAA is redundant. Moved, or
completely dismissed reads of @tail in consumer code, are not a problem at
since @tail is written exclusively by CONSUMER side.

> It is also within
> its rights to do piece-at-a-time loads and stores, which might sound
> unlikely, but which can actually has happened when the compiler figures
> out exactly what is to be stored at compile time, especially on hardware
> that only allows small immediate values.

As for writes to @tail, the ACCESS_ONCE around @tail at point AAA,
doesn't prevent in any way an imaginary super-optimizing compiler
from moving around the store to @tail (which appears in the code at point

It is why ACCESS_ONCE at point AAA is completely redundant.

-- 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
Please read the FAQ at