From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKCNi-0008Ig-FI for qemu-devel@nongnu.org; Mon, 04 Jul 2016 18:30:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKCNd-0005rS-E1 for qemu-devel@nongnu.org; Mon, 04 Jul 2016 18:30:21 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:38520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKCNa-0005mC-Vq for qemu-devel@nongnu.org; Mon, 04 Jul 2016 18:30:17 -0400 Date: Mon, 4 Jul 2016 18:30:01 -0400 From: "Emilio G. Cota" Message-ID: <20160704223001.GA29624@flamenco> References: <1467389770-9738-1-git-send-email-alex.bennee@linaro.org> <1467389770-9738-3-git-send-email-alex.bennee@linaro.org> <20160702003942.GB2295@flamenco> <87lh1hmxsf.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87lh1hmxsf.fsf@linaro.org> Subject: Re: [Qemu-devel] [PATCH 2/2] cpu-exec: remove tb_lock from the hot-path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex =?iso-8859-1?Q?Benn=E9e?= Cc: mttcg@listserver.greensocs.com, qemu-devel@nongnu.org, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, serge.fdrv@gmail.com, bobby.prani@gmail.com, rth@twiddle.net, mark.burton@greensocs.com, pbonzini@redhat.com, jan.kiszka@siemens.com, peter.maydell@linaro.org, claudio.fontana@huawei.com, Peter Crosthwaite On Mon, Jul 04, 2016 at 12:45:52 +0100, Alex Bennée wrote: > > Emilio G. Cota writes: > > > On Fri, Jul 01, 2016 at 17:16:10 +0100, Alex Bennée wrote: > >> Lock contention in the hot path of moving between existing patched > >> TranslationBlocks is the main drag in multithreaded performance. This > >> patch pushes the tb_lock() usage down to the two places that really need > >> it: > >> > >> - code generation (tb_gen_code) > >> - jump patching (tb_add_jump) > >> > >> The rest of the code doesn't really need to hold a lock as it is either > >> using per-CPU structures, atomically updated or designed to be used in > >> concurrent read situations (qht_lookup). > >> > >> To keep things simple I removed the #ifdef CONFIG_USER_ONLY stuff as the > >> locks become NOPs anyway until the MTTCG work is completed. > > > > From a scalability point of view it would be better to have a single > > critical section. > > You mean merge the critical region for patching and code-generation? Yes, I'd keep the lock held and drop it (if it was held) after the patching is done, like IIRC we used to do: (snip) > > I propose to just extend the critical section, like we used to > > do with tcg_lock_reset. E.