On Sun, Jul 22, 2018 at 06:42:45PM -0700, Artem Polyakov wrote:
> Hello,
> I have a question about the following scenario (considering POWER arch):
>
> initial { x = 0; y = 0; }
>
> thread0 {
> x = 1;
> lwsync;
> y = 1;
> }
>
> thread1 {
> a = y;
> isync;
> b = x;
> }
>
> Because "isync" is not a memory barrier this example doesn't have
> read/write barrier pairing. However, if I understand correctly, lwsync will
> ensure that "x = 1" will become visible to thread1 before lwsync is done
> and before "y = 1" will become visible. So "isync" here can be sort of
> control dependency as it ensures that "a = y" will be performed before "b =
> x" and even will flush the pipeline according to POWER9 spec.
>
> Can someone comment on this scenario and tell if I am right or where I am
> wrong.
I am not a Power hardware architect, but here is my understanding.
The isync waits until all the prior instructions "execute", but for
a limited definition of "execute". One way to think of isync is as
an instruction that does not allow subsequent instructions to start
until it can be proven that execution really will reach the isync
instruction.
So given a load, how could it be that execution would be prevented
from reaching the isync instruction? One possibility is a SEGV.
But once address translation completes successfully, SEGV cannot
happen. So isync doesn't need to wait for the load to return an
actual value, but instead only for its execution to reach a point
where the hardware knows that a value will eventually be returned.
And that is why you need a compare and conditional branch before the
isync to ensure that the load has completed. In that case, the
hardware cannot prove that execution will actually reach the isync
until the load completes, the compare sets the condition code,
and the branch condition is evaluated. Therefore, anything after
the compare-branch-isync series cannot start executing until after
the load returns its value.
Make sense, or am I missing the point of your question?
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
