On Mon, Jun 25, 2018 at 08:44:14AM -0700, Daniel Lustig wrote: > RISC-V is (other-)multi-copy-atomic, so I don't think transitivity > should be an issue here. Ah, ok. > We do have a "fence w,r", but we decided to warn against actually using > it for a few reasons: 1) lack of known common use cases :), 2) IIRC > there was some corner case discrepancy between the axiomatic and > operational models if we allowed it, and 3) in practice, it's already > both expensive enough and obscure enough that many or most > implementations will simply just treat it as "fence rw,rw" anyway. Because the majority of the cost is flushing the store-buffer in either case? > So, in theory, "fence w,r" should be enough to prevent SB-like patterns. > It's just not yet clear that it's a big enough win that it's worth > creating a new fence macro for it, or pulling the current RISC-V > recommendation against its use. What do you all think? It was mostly a theoretical argument for why smp_mb() is too strong, not a real practical desire to have w,t. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
