From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5IRF-0005c8-Qd for qemu-devel@nongnu.org; Tue, 24 May 2016 15:56:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5IRC-0001x1-JZ for qemu-devel@nongnu.org; Tue, 24 May 2016 15:56:25 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:33883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5IRA-0001vW-7M for qemu-devel@nongnu.org; Tue, 24 May 2016 15:56:22 -0400 Date: Tue, 24 May 2016 15:56:09 -0400 From: "Emilio G. Cota" Message-ID: <20160524195609.GA30809@flamenco> References: <1463863336-28760-1-git-send-email-cota@braap.org> <1463863336-28760-2-git-send-email-cota@braap.org> <20160523170912.GA16390@flamenco> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Paolo Bonzini Cc: Richard Henderson , MTTCG Devel , Alex =?iso-8859-1?Q?Benn=E9e?= , QEMU Developers , Sergey Fedorov 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. Thanks, Emilio