It is selectable only for MIPS R2 but not MIPS R6. The reason is - most ofWhat ?! Are you saying that because R2 has short pipelines its unlikely
MIPS R2 CPUs have short pipeline and that SYNC is just waste of CPU
resource, especially taking into account that "lightweight syncs" are
converted to a heavy "SYNC 0" in many of that CPUs. However the latest
MIPS/Imagination CPU have a pipeline long enough to hit a problem - absence
of SYNC at LL/SC inside atomics, barriers etc.
to hit the reordering issues and we can omit barriers?
That did not in fact enlighten things. Are they transitive/multi-copyAnd reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12Please see above, point 2.
are_NOT_ transitive and therefore cannot be used to implement the
smp_mb__{before,after} stuff.
That is, in MIPS speak, those SYNC types are Ordering Barriers, not
Completion Barriers.
atomic or not?
(and here Will will go into great detail on the differences between the
two and make our collective brains explode :-)
From: lkml.kernel.org/r/20150828153921.GF19282@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxThat is, currently all architectures -- with exception of PPC -- haveI don't understand that - I tried hard but I can't find any word like
RCsc locks, but using these non-transitive things will get you RCpc
locks.
So yes, MIPS can go RCpc for its locks and share the burden of pain with
PPC, but that needs to be a very concious decision.
"RCsc", "RCpc" in Documents/ directory. Web search goes nowhere, of course.
Yes, the difference between RCpc and RCsc is in the meaning of RELEASE +
ACQUIRE. With RCsc that implies a full memory barrier, with RCpc it does
not.
Currently PowerPC is the only arch that (can, and) does RCpc and gives a
weaker RELEASE + ACQUIRE. Only the CPU who did the ACQUIRE is guaranteed
to see the stores of the CPU which did the RELEASE in order.