From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753053AbbEHSSw (ORCPT ); Fri, 8 May 2015 14:18:52 -0400 Received: from mail.kernel.org ([198.145.29.136]:48744 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752226AbbEHSSt (ORCPT ); Fri, 8 May 2015 14:18:49 -0400 Date: Fri, 8 May 2015 15:18:44 -0300 From: Arnaldo Carvalho de Melo To: Will Deacon Cc: Peter Zijlstra , Ingo Molnar , David Ahern , Jiri Olsa , Namhyung Kim , Linux Kernel Mailing List Subject: Re: Question about barriers for ARM on tools/perf/ Message-ID: <20150508181844.GN7862@kernel.org> References: <20150508140459.GI7862@kernel.org> <20150508142107.GA25587@arm.com> <20150508142513.GM27504@twins.programming.kicks-ass.net> <20150508143729.GJ7862@kernel.org> <20150508144820.GD25587@arm.com> <20150508145701.GL7862@kernel.org> <20150508152759.GO27504@twins.programming.kicks-ass.net> <20150508164534.GK25587@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150508164534.GK25587@arm.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, May 08, 2015 at 05:45:35PM +0100, Will Deacon escreveu: > On Fri, May 08, 2015 at 04:27:59PM +0100, Peter Zijlstra wrote: > > On Fri, May 08, 2015 at 11:57:01AM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Fri, May 08, 2015 at 03:48:20PM +0100, Will Deacon escreveu: > > > > Do you know what the objection to the intrinsics was? I believe that > > > > the __sync versions are deprecated in favour of the C11-like __atomic > > > > flavours, so if that was all the objection was about then we could use > > > > one or the other depending on what the compiler supports. > > > Peter? Ingo? > > I cannot remember, the __sync things should mostly work I suppose, and > > if you wrap then in the normal atomic interface we don't have to learn > > yet another API. > Yeah, I think that's a good idea. I'll use what I have, that is what I posted, i.e. something that was tested. As we test it further, then we can either lift more stuff from the kernel or add more compiler-foo.h stuff like we have in the kernel. > > That said, I've successfully lifted this kernel code into userspace in > > the past. > > Lifting a copy isn't too bad, it's using the same file that worries me. So that is how I'll proceed, lifting a copy of just what I need, lifting more as the need arises, and fallbacking to gcc intrinsics for architectures where the implementations drag too much stuff. Over time, as the need arises, maybe to support some older compiler or some problematic toolchain, lifting more from the kernel may be desired and should be considered. - Arnaldo