From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alNYX-0001CV-9P for qemu-devel@nongnu.org; Wed, 30 Mar 2016 17:21:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alNYU-0000GV-0Q for qemu-devel@nongnu.org; Wed, 30 Mar 2016 17:21:37 -0400 Received: from mail-lb0-x242.google.com ([2a00:1450:4010:c04::242]:33278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alNYT-0000G9-OJ for qemu-devel@nongnu.org; Wed, 30 Mar 2016 17:21:33 -0400 Received: by mail-lb0-x242.google.com with SMTP id bc4so5298823lbc.0 for ; Wed, 30 Mar 2016 14:21:33 -0700 (PDT) References: <56FC0818.10002@linaro.org> <56FC2430.1010606@twiddle.net> From: Sergey Fedorov Message-ID: <56FC435B.6060708@gmail.com> Date: Thu, 31 Mar 2016 00:21:31 +0300 MIME-Version: 1.0 In-Reply-To: <56FC2430.1010606@twiddle.net> 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: Richard Henderson , Sergey Fedorov , QEMU Developers , Paolo Bonzini , Peter Crosthwaite Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= On 30/03/16 22:08, Richard Henderson wrote: > On 03/30/2016 10:08 AM, Sergey Fedorov wrote: >> As of catching tb_flush() in cpu_exec() there have been three approaches >> proposed. >> >> The first approach is to get rid of 'tb_invalidated_flag' and use >> 'tb_flush_count'. Capture 'tb_flush_count' inside 'tb_lock' critical >> section of cpu_exec() and compare it on each execution loop iteration >> before trying to do tb_add_jump(). This would be simple and clear but it >> would cost an extra load from a shared variable 'tb_flush_count' each >> time we go over the execution loop. >> >> The second approach is to make 'tb_invalidated_flag' per-CPU. This >> would be conceptually similar to what we have, but would give us thread >> safety. With this approach, we need to be careful to correctly clear and >> set the flag. >> >> The third approach is to mark each individual TB as valid/invalid. This >> is what Emilio has in his MTTCG series [2]. Following this approach, we >> could have very clean code with no extra overhead on the hot path. >> However, it would require to mark all TBs as invalid on tb_flush(). >> Given that tb_flush() is rare, it shouldn't be a significant overhead. >> Also, there could be several options how to mark TB valid/invalid: >> a dedicated flag could be introduced or some invalid value of >> pc/cs_base/flags could be used. > I'm not really fond of this third option. Yes, tb_flush is rare on some > targets, but for those with software managed TLBs they're much more common. > See e.g. mips and sparc. > > Even when tb_flush is rare, there can be 500k-1M TBs live when the flush does > happen. I simply cannot imagine that individually touching 1M variables > performs as well as setting one global variable, or taking a global lock. Ah, you are right, I missed that fact, thanks. Kind regards, Sergey