From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934287AbcJRS6p (ORCPT ); Tue, 18 Oct 2016 14:58:45 -0400 Received: from smtprelay.synopsys.com ([198.182.60.111]:51160 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932426AbcJRS6h (ORCPT ); Tue, 18 Oct 2016 14:58:37 -0400 Subject: Re: [RFC] perf: fix building for ARCv1 To: Peter Zijlstra 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> CC: Alexey Brodkin , "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , Russell King , arcml , "acme@redhat.com" From: Vineet Gupta Message-ID: <9e22e4b1-7e36-1a74-3620-a4790a5d1bfd@synopsys.com> Date: Tue, 18 Oct 2016 11:58:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20151019093549.GK3816@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.161.38] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/19/2015 02:35 AM, 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. So I got around to addressing this - now that someone actually is trying to use NPTL (which uses llock/scond) on ARC700 lacking those instructions. However given that we are going this route, FWIW ARM kernel got rid of this syscall with db695c0509d6ec ("ARM: remove user cmpxchg syscall") citing some security hole. Even of we were to disregard, the code at the time had some open code MM trickery, which I'd rather not replicate. My use case is simple - I only need to support UP config - and a simple {get,put}_user would suffice - given that that can potentially take a TLB refill Miss or worse still a full page fault. I'm going to cook that patch to add that syscall, but wanted to get some thoughts ahead of that. -Vineet