From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agxap-0005ws-JY for qemu-devel@nongnu.org; Fri, 18 Mar 2016 12:49:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agxam-00053B-B3 for qemu-devel@nongnu.org; Fri, 18 Mar 2016 12:49:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agxam-000531-6F for qemu-devel@nongnu.org; Fri, 18 Mar 2016 12:49:40 -0400 References: <1458317932-1875-1-git-send-email-alex.bennee@linaro.org> <1458317932-1875-10-git-send-email-alex.bennee@linaro.org> From: Paolo Bonzini Message-ID: <56EC319D.9030009@redhat.com> Date: Fri, 18 Mar 2016 17:49:33 +0100 MIME-Version: 1.0 In-Reply-To: <1458317932-1875-10-git-send-email-alex.bennee@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC v1 09/11] tcg: drop global lock during TCG code execution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= , mttcg@greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, serge.fdrv@gmail.com, cota@braap.org Cc: Eduardo Habkost , "Michael S. Tsirkin" , Peter Crosthwaite , mark.burton@greensocs.com, qemu-devel@nongnu.org, Richard Henderson On 18/03/2016 17:18, Alex Benn=C3=A9e wrote: > From: KONRAD Frederic >=20 > This finally allows TCG to benefit from the iothread introduction: Drop > the global mutex while running pure TCG CPU code. Reacquire the lock > when entering MMIO or PIO emulation, or when leaving the TCG loop. >=20 > We have to revert a few optimization for the current TCG threading > model, namely kicking the TCG thread in qemu_mutex_lock_iothread and no= t > kicking it in qemu_cpu_kick. We also need to disable RAM block > reordering until we have a more efficient locking mechanism at hand. >=20 > Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here. > These numbers demonstrate where we gain something: >=20 > 20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-syste= m-arm > 20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-syste= m-arm >=20 > The guest CPU was fully loaded, but the iothread could still run mostly > independent on a second core. Without the patch we don't get beyond >=20 > 32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-syste= m-arm > 32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-syste= m-arm >=20 > We don't benefit significantly, though, when the guest is not fully > loading a host CPU. >=20 > Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.c= om> > Signed-off-by: KONRAD Frederic > [AJB: -smp single-threaded fix, rm old info from commit msg] > Signed-off-by: Alex Benn=C3=A9e You should probably squash this and patch 10 together. Paolo