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
