From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqm9C-0003sM-9I for qemu-devel@nongnu.org; Thu, 14 Apr 2016 14:37:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqm99-0007ld-3r for qemu-devel@nongnu.org; Thu, 14 Apr 2016 14:37:46 -0400 Received: from mail-lf0-x243.google.com ([2a00:1450:4010:c07::243]:36337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqm98-0007lT-S6 for qemu-devel@nongnu.org; Thu, 14 Apr 2016 14:37:43 -0400 Received: by mail-lf0-x243.google.com with SMTP id 13so1293752lfz.3 for ; Thu, 14 Apr 2016 11:37:42 -0700 (PDT) References: <1458222382-6498-1-git-send-email-sergey.fedorov@linaro.org> <1458222382-6498-5-git-send-email-sergey.fedorov@linaro.org> <56EAC8A2.7060700@redhat.com> <56EAC9E3.60000@gmail.com> <56F94B59.80905@gmail.com> <56F9A051.9090907@redhat.com> <56FA52E3.3000900@gmail.com> <56FA5ADB.7030103@redhat.com> <570FACF1.6020009@gmail.com> <570FB396.6040703@redhat.com> From: Sergey Fedorov Message-ID: <570FE374.5040607@gmail.com> Date: Thu, 14 Apr 2016 21:37:40 +0300 MIME-Version: 1.0 In-Reply-To: <570FB396.6040703@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , sergey.fedorov@linaro.org, qemu-devel@nongnu.org Cc: Richard Henderson , Peter Crosthwaite , =?UTF-8?Q?Alex_Benn=c3=a9e?= On 14/04/16 18:13, Paolo Bonzini wrote: > On 14/04/2016 16:45, Sergey Fedorov wrote: >> Personally, I'm not so >> happy trying to use pc/cs_base/flags to mark an invalid TB. Are my >> worries unreasonable? :) > Can you explain your worries? > > The advantages are that it's O(1) and it obviously doesn't affect other > TBs than the invalidated one. Well, it looks a bit hucky, I don't like hucky code because it is each time hard to read, modify and be confident in it. I would like to introduce a dedicated boolean field to mark a TB as valid/invalid. But this approach adds one more compare in tb_find_fast() and tb_find_slow(). Luckily, it may be not an issue if my proposal with memory barriers and atomic access to 'tb_jmp_cache' solves the problem. Kind regards, Sergey