Joakim Tjernlund wrote:
different since descriptors are in MURAM which is ioremap()ed -- though
switching to a cacheable mapping with barriers should be a performance
improvement.
I always thought that MURAM was very fast. The whole reason to have BDs in
MURAM is that it is faster than normal RAM, at least that is what I
thought.
Yeah, on second thought it probably wouldn't be worth it. There's also
the question of under what circumstances the QE's MURAM accesses will be
cache-coherent.
As for the CPU not reordering guarded+cache inhibited accesses, that
initially seemed to be true for the new arch stuff (book3e/book3s, but
not really, see below), but the classic arch documentation only
guarantees stores to such regions to be in-order (and the
explicitly-specified operation of eieio on I+G accesses wouldn't make
much sense if they were already guaranteed to be in-order).
Then I looked at the EREF to see what older book E documents had to say
on the issue, and it suggests that when the architecture document says
"out of order", it really means "speculative" (and reading the arch
doc's definition of "out of order" seems to confirm this -- redefining
terms is bad, m'kay?). So it seems that the simple answer is no,
guarded storage is not guaranteed to be in order, unless the only thing
that can cause an out-of-order access is speculative execution.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
