Messages in this thread | | | Date | Mon, 25 Jun 2018 18:38:28 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] doc: Update wake_up() & co. memory-barrier guarantees |
| |
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.
| |