From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPtfB-0004Tm-Bi for qemu-devel@nongnu.org; Thu, 13 Aug 2015 10:39:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPtf7-0004Dv-5R for qemu-devel@nongnu.org; Thu, 13 Aug 2015 10:39:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPtf7-0004Df-04 for qemu-devel@nongnu.org; Thu, 13 Aug 2015 10:39:21 -0400 References: <1439397664-70734-1-git-send-email-pbonzini@redhat.com> <1439397664-70734-12-git-send-email-pbonzini@redhat.com> <55CC92CC.4020201@greensocs.com> <55CC9496.8050905@redhat.com> <55CC9C6A.4070309@greensocs.com> From: Paolo Bonzini Message-ID: <55CCAC0C.5090200@redhat.com> Date: Thu, 13 Aug 2015 16:39:08 +0200 MIME-Version: 1.0 In-Reply-To: <55CC9C6A.4070309@greensocs.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 11/10] tcg: comment on which functions have to be called with tb_lock held List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frederic Konrad , qemu-devel@nongnu.org Cc: mttcg@greensocs.com 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. >=20 > 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