From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPFZ8-0004Ea-KA for qemu-devel@nongnu.org; Mon, 18 Jul 2016 16:55:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPFZ5-0000pv-By for qemu-devel@nongnu.org; Mon, 18 Jul 2016 16:55:02 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:36535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPFZ5-0000pr-4g for qemu-devel@nongnu.org; Mon, 18 Jul 2016 16:54:59 -0400 Received: by mail-wm0-x22f.google.com with SMTP id f126so118136442wma.1 for ; Mon, 18 Jul 2016 13:54:58 -0700 (PDT) Sender: Paolo Bonzini References: <1468851450-9863-1-git-send-email-pbonzini@redhat.com> <578D0938.2050004@gmail.com> <578D0A60.4020608@gmail.com> <8c52110d-c009-087c-be04-3920d97af323@redhat.com> <578D0CD6.3080005@gmail.com> <4c479cb3-a8ef-caab-4dbc-3bfd014c7a0a@redhat.com> <578D0F42.4040203@gmail.com> <84ba6ace-e0bd-515a-5194-2e6704d22805@redhat.com> <578D1126.4060803@gmail.com> <578D1285.8060303@gmail.com> <67224898-07f6-d7a1-283f-a764f51a4993@redhat.com> <578D2821.6010408@gmail.com> From: Paolo Bonzini Message-ID: <13032d05-0ddc-42ae-6e25-2b13ef535f4f@redhat.com> Date: Mon, 18 Jul 2016 22:54:55 +0200 MIME-Version: 1.0 In-Reply-To: <578D2821.6010408@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] atomics: add volatile_read/volatile_set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov , qemu-devel@nongnu.org Cc: alex.bennee@linaro.org, sergey.fedorov@linaro.org On 18/07/2016 21:04, Sergey Fedorov wrote: > How much performance do we really need and how much performance can we > loose introducing such a flag? We should yet gain something reducing > tb_lock contention. Maybe it is worthwhile to use a dedicated flag to > keep code more clear? There's always a question of balance between code > structure and maintainability (future of the TCG) on one hand and > performance (present of the TCG) on the other hand. Fair enough, can you send a patch that does this? If we can do the check only just before tb_add_jump, indeed there's no reason to do all the mess with invalid state. Paolo