Messages in this thread | | | Date | Thu, 31 Oct 2013 12:11:21 +0100 | From | Paolo Bonzini <> | Subject | Re: [PATCH RFC] kvm: optimize out smp_mb using srcu_read_unlock |
| |
Il 31/10/2013 07:47, Gleb Natapov ha scritto: > This looks dubious to me. All other smp_mb__after_* variants are there > because some atomic operations have different memory barrier semantics on > different arches,
It doesn't have to be arches; unlock APIs typically have release semantics only, but SRCU is stronger.
> but srcu_read_unlock() have the same semantics on all > arches, so smp_mb__after_srcu_read_unlock() becomes > smp_mb__after_a_function_that_happens_to_have_mb_now_but_may_not_have_in_the_feature(). > How likely it is that smp_mb() will disappear from srcu_read_unlock() > (if was added for a reason I guess)? May be we should change documentation > to say that srcu_read_unlock() is a memory barrier which will reflect > the reality.
That would be different from all other unlock APIs.
Paolo
| |