From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753882AbbJSJql (ORCPT ); Mon, 19 Oct 2015 05:46:41 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:56793 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753631AbbJSJqk convert rfc822-to-8bit (ORCPT ); Mon, 19 Oct 2015 05:46:40 -0400 From: Vineet Gupta To: Peter Zijlstra CC: Andi Kleen , Alexey Brodkin , Aabid Rushdi , "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , "dvhart@linux.intel.com" , "dsahern@gmail.com" , "acme@redhat.com" Subject: Re: [RFC] perf: fix building for ARCv1 Thread-Topic: [RFC] perf: fix building for ARCv1 Thread-Index: AQHRCjH5qUIZ06l560WdnGKbYbcPAw== Date: Mon, 19 Oct 2015 09:46:35 +0000 Message-ID: References: <1445088959-3058-1-git-send-email-abrodkin@synopsys.com> <1445166916.9672.10.camel@synopsys.com> <87a8rf6a6p.fsf@tassilo.jf.intel.com> <8761235rwe.fsf@tassilo.jf.intel.com> <20151019093549.GK3816@twins.programming.kicks-ass.net> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.239.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 19 October 2015 03:05 PM, Peter Zijlstra wrote: > On Mon, Oct 19, 2015 at 09:28:43AM +0000, Vineet Gupta wrote: >> > On Monday 19 October 2015 11:20 AM, Andi Kleen wrote: >>> > > Vineet Gupta writes: >>>> > >> But this user space - so IMHO UP/SMP doesn't matter and we can't simulate them in >>>> > >> C just by itself. >>> > > It matters when you access the perf ring buffer which is updated by kernel. >> > >> > That's part of the problem. The issue is with atomic_* APIs proliferation in perf >> > user space code which assumes native atomix r-m-w support which is not always >> > true. So I think we still need a feature detection mechanism and if absent leave >> > the ball in arch court by calling arch_atomic_* which can use creative or half >> > working measures so perf will work to some extent atleast and not bomb outright. >> > >> > Also can u please elaborate a bit on "simulate them in C" - u mean just simple >> > unprotected LD, OP, ST or do u fancy usage of futex etc? > Doesn't ARMv5 have a cmpxchg syscall to deal with this? It does an > IRQ-disabled load-op-store sequence. Yeah I remember seeing some syscall like that in ARM. On ARC we could use the atomic EXchange to implement a user space only binary semaphore - these atomic ops will be small duration so it is OK to spin wait for a little bit. That's how the old pthread library worked for ARC w/o any atomic support.