From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLF2z-0005aV-3K for qemu-devel@nongnu.org; Thu, 07 Jul 2016 15:33:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLF2t-0005lH-15 for qemu-devel@nongnu.org; Thu, 07 Jul 2016 15:33:16 -0400 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:36990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLF2s-0005kV-84 for qemu-devel@nongnu.org; Thu, 07 Jul 2016 15:33:10 -0400 Received: by mail-wm0-x22b.google.com with SMTP id k123so3277158wme.0 for ; Thu, 07 Jul 2016 12:33:09 -0700 (PDT) References: <1467735496-16256-1-git-send-email-alex.bennee@linaro.org> <20160707160439.GA28053@flamenco> <21e93a61-c942-b503-c592-bc68b55454cd@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <21e93a61-c942-b503-c592-bc68b55454cd@redhat.com> Date: Thu, 07 Jul 2016 20:33:10 +0100 Message-ID: <878txdmefd.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 0/6] Reduce lock contention on TCG hot-path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Emilio G. Cota" , mttcg@listserver.greensocs.com, peter.maydell@linaro.org, claudio.fontana@huawei.com, jan.kiszka@siemens.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, serge.fdrv@gmail.com, bobby.prani@gmail.com, rth@twiddle.net, fred.konrad@greensocs.com Paolo Bonzini writes: > On 07/07/2016 18:04, Emilio G. Cota wrote: >>> > I think the first 3 patches are ready to take if the TCG maintainers >>> > want to: >>> > >>> > tcg: Ensure safe tb_jmp_cache lookup out of 'tb_lock' >>> > tcg: set up tb->page_addr before insertion >>> > tcg: cpu-exec: remove tb_lock from the hot-path >> I think it would be simpler to use tb_lock_recursive and >> tb_lock_reset, as pointed out in v1 of this series. > > I agree, this series is doing a lot more restructuring than necessary. Really I thought the first 3 patches where simplifying things - that's why I moved the more aggressive stuff into follow on patches. Wouldn't using tb_lock_recursive inside the mmap_lock() run the risk of a deadlock? > > Paolo -- Alex Bennée