Re: [Qemu-devel] [PATCH 11/10] tcg: comment on which functions have to be called with tb_lock held

[Paolo Bonzini]

On 13/08/2015 15:32, Frederic Konrad wrote:
>> I've now extracted parts of your patch "tcg: protect TBContext with
>> tb_lock" into a separate "tcg: move tb_find_fast outside the tb_lock
>> critical section" that also applies to user-mode emulation.  That way I
>> get good scalability on Dhrystone, same as with your branch.
> 
> I guess with the whole tlb/tb flush safe?

Yes, that should go before the lock-free tb_find_fast.

> Which is theorically
> protecting tb_jmp_cache (or at least let only the right thread
> accessing it). The drawback of all that is I'm not sure this is
> faster when we have a lot of context switches. For tb_flush it's not
> really a problem as it happen approximately never but the
> tb_invalidate, tlb_*_flush are more regular.

TBs are physically-tagged so invalidates are not too frequent unless the
guest does self-modifying code or swaps.  They shouldn't be a source of
tb_lock contention except if you do SMC (not just dynamic recompilation:
really self-modifying code).

TBs are a good match for RCU overall.  TB data is immutable if you
sacrifice the tb_phys_hash optimization, so there's no need to copy
anything, hence modifications to the lists are rare and reclamations
(tb_flush) are extremely rare.

TLB shootdowns of course will slow down things, but those are a separate
issue and we don't really care: the ARM flush-all-CPUs is probably
faster than an IPI anyway.

Paolo