On 15/07/16 15:51, Paolo Bonzini wrote: > > On 15/07/2016 14:37, Sergey Fedorov wrote: >> I understand why an implied wmb can be expected after the entry is >> removed: so that the caller can trash the contents of the object >> removed. However that would require double-check on lookup side to make >> sure the entry hadn't been removed after the first lookup (something >> like seqlock read side). But I have no idea why we might like to promise >> wmb before the removal. Could you please share your point regarding this? > The reasoning was to make qht_remove() "look to be ordered" with respect > to writes. So anything after remove wouldn't bleed into it, nor would > anything before. > > In the case of this series, it would let you remove the smp_wmb() after > tb_mark_invalid(). However, it's also okay to only handle qht_insert() > and qht_lookup(), and keep the memory barrier after the TB is marked > invalid (though it is unnecessary). >
I'm pretty sure the smp_wmb() after tb_mark_invalid() is unnecessary anyway. We don't rely on it at all because we're to recheck for tb_is_invalid() under tb_lock before tb_add_jump(). However we have to invalidate the CPU state atomically since we're going to check for it out of tb_lock. Kind regards, Sergey
