From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aldpq-0003nu-C6 for qemu-devel@nongnu.org; Thu, 31 Mar 2016 10:44:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aldpm-0002fd-Be for qemu-devel@nongnu.org; Thu, 31 Mar 2016 10:44:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aldpm-0002fZ-65 for qemu-devel@nongnu.org; Thu, 31 Mar 2016 10:44:30 -0400 References: <56FC0818.10002@linaro.org> <56FC174A.6070906@redhat.com> <56FD22A5.10501@gmail.com> <56FD28BB.6030305@redhat.com> <56FD35C8.6060900@gmail.com> From: Paolo Bonzini Message-ID: <56FD37C9.4070807@redhat.com> Date: Thu, 31 Mar 2016 16:44:25 +0200 MIME-Version: 1.0 In-Reply-To: <56FD35C8.6060900@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] tcg: reworking tb_invalidated_flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov , Sergey Fedorov , QEMU Developers , Richard Henderson , Peter Crosthwaite Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= On 31/03/2016 16:35, Sergey Fedorov wrote: >> > My plan was to use some kind of double buffering, where only half of >> > code_gen_buffer is in use. At the end of tb_flush you call cpu_exit() >> > on all CPUs, so that CPUs stop executing chained TBs from the old half >> > before they can see one from the new half. >> > >> > If code_gen_buffer is static you have to preallocate two buffers (and >> > two tbs arrays) and waste one of them; while it is theoretically >> > possible to have CPUs still executing from the old half while you finish >> > the new half, it can be more or less ignored. >> > >> > If it is dynamic, the previously used areas can be freed with call_rcu, >> > and you can safely allocate a new code_gen_buffer and tbs array. >> > >> > I haven't thought much about it; it might require keeping a cache of the >> > tbs array per CPU, and possibly changing the code under "if >> > (tcg_ctx.tb_ctx.tb_invalidated_flag)" to simply exit cpu_exec. > Maybe save this idea for latter? :) We'd better use a simpler approach > at first and then move on and optimize. BTW, a few years ago I came > across an interesting paper on code cache eviction granularities [1]. It depends on what is simpler. Emilio and Fred's code was tricky and touched the central CPU execution loop in cpus.c. Paolo