From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753525AbbEHOZ1 (ORCPT ); Fri, 8 May 2015 10:25:27 -0400 Received: from casper.infradead.org ([85.118.1.10]:38409 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752691AbbEHOZZ (ORCPT ); Fri, 8 May 2015 10:25:25 -0400 Date: Fri, 8 May 2015 16:25:13 +0200 From: Peter Zijlstra To: Will Deacon Cc: Arnaldo Carvalho de Melo , Ingo Molnar , David Ahern , Jiri Olsa , Namhyung Kim , Linux Kernel Mailing List Subject: Re: Question about barriers for ARM on tools/perf/ Message-ID: <20150508142513.GM27504@twins.programming.kicks-ass.net> References: <20150508140459.GI7862@kernel.org> <20150508142107.GA25587@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150508142107.GA25587@arm.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 08, 2015 at 03:21:08PM +0100, Will Deacon wrote: > Wouldn't it be better to go the other way, and use compiler builtins for > the memory barriers instead of relying on the kernel? It looks like the > perf_mmap__{read,write}_head functions are basically just acquire/release > operations and could therefore be implemented using something like > __atomic_load_n(&pc->data_head, __ATOMIC_ACQUIRE) and > __atomic_store_n(&pc->data_tail, tail, __ATOMIC_RELEASE). He wants to do smp refcounting, which needs atomic_inc() / atomic_inc_non_zero() / atomic_dec_return() etc..