From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5IUm-0008UN-Ja for qemu-devel@nongnu.org; Tue, 24 May 2016 16:00:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5IUi-0002nt-Dl for qemu-devel@nongnu.org; Tue, 24 May 2016 16:00:03 -0400 Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:36631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5IUi-0002n1-5w for qemu-devel@nongnu.org; Tue, 24 May 2016 16:00:00 -0400 Received: by mail-lb0-x22e.google.com with SMTP id h1so8956500lbj.3 for ; Tue, 24 May 2016 12:59:59 -0700 (PDT) References: <1463863336-28760-1-git-send-email-cota@braap.org> <1463863336-28760-2-git-send-email-cota@braap.org> <20160523170912.GA16390@flamenco> <20160524195609.GA30809@flamenco> From: Sergey Fedorov Message-ID: <5744B2BD.5000705@gmail.com> Date: Tue, 24 May 2016 22:59:57 +0300 MIME-Version: 1.0 In-Reply-To: <20160524195609.GA30809@flamenco> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] atomics: do not use __atomic primitives for RCU atomics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Emilio G. Cota" , Paolo Bonzini Cc: Richard Henderson , MTTCG Devel , =?UTF-8?Q?Alex_Benn=c3=a9e?= , QEMU Developers On 24/05/16 22:56, Emilio G. Cota wrote: > On Tue, May 24, 2016 at 09:08:01 +0200, Paolo Bonzini wrote: >> On 23/05/2016 19:09, Emilio G. Cota wrote: >>> PS. And really equating smp_wmb/rmb to release/acquire as we have under >>> #ifdef __ATOMIC is hard to justify, other than to please tsan. >> That only makes a difference on arm64, right? >> >> acquire release rmb wmb >> x86 -- -- -- -- >> power lwsync lwsync lwsync lwsync >> armv7 dmb dmb dmb dmb >> arm64 dmb ishld dmb ish dmb ishld dmb ishst >> ia64 -- -- -- -- > Yes. I now see why we're defining rmb/wmb based on acquire/release: > it's quite convenient given that the compiler provides them, and > the (tiny) differences in practice are not worth the trouble of > adding asm for them. So I take back my comment =) > > The gains of getting rid of the consume barrier from atomic_rcu_read > are clear though; updated patch to follow. However, maybe it's not such a pain to maintain an optimized version for AArch64 in assembly :P Best, Sergey