From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932929AbcBCQVF (ORCPT ); Wed, 3 Feb 2016 11:21:05 -0500 Received: from smtprelay.synopsys.com ([198.182.60.111]:33735 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbcBCQVD (ORCPT ); Wed, 3 Feb 2016 11:21:03 -0500 From: Alexey Brodkin To: Vineet Gupta CC: "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "tglx@linutronix.de" , "andi@firstfloor.org" , "linux-snps-arc@lists.infradead.org" , "acme@redhat.com" , "linux-perf-users@vger.kernel.org" , "giladb@ezchip.com" , "dsahern@gmail.com" , "dvhart@linux.intel.com" , "noamc@ezchip.com" Subject: Re: [RFC] perf: fix building for ARCv1 Thread-Topic: [RFC] perf: fix building for ARCv1 Thread-Index: AQHRCjH5qUIZ06l560WdnGKbYbcPA58bGI+A Date: Wed, 3 Feb 2016 16:20:56 +0000 Message-ID: <1454516455.2811.4.camel@synopsys.com> References: <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> <20151019095157.GM3816@twins.programming.kicks-ass.net> <20151020101133.GA17308@twins.programming.kicks-ass.net> <1446134296.3203.27.camel@synopsys.com> In-Reply-To: Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.171] Content-Type: text/plain; charset="utf-8" Content-ID: <1C4C0DD35AD39349AB8A56D688DF15D1@internal.synopsys.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u13GLBgi030134 Hi Vineet, On Fri, 2015-10-30 at 06:19 +0000, Vineet Gupta wrote: > On Thursday 29 October 2015 09:28 PM, Alexey Brodkin wrote: > > Hi Vineet, > > > > On Tue, 2015-10-20 at 10:45 +0000, Vineet Gupta wrote: > > > On Tuesday 20 October 2015 03:41 PM, Peter Zijlstra wrote: > > > > > > Can we use existing syscall(s) - again this is what our good old pthread library > > > > > > code did. > > > > > > > > > > > > static void __pthread_acquire(int * spinlock) > > > > > > { > > > > > > int cnt = 0; > > > > > > struct timespec tm; > > > > > > > > > > > > READ_MEMORY_BARRIER(); > > > > > > > > > > > > while (testandset(spinlock)) { <---- atomic EXchange > > > > > > if (cnt < 50) { > > > > > > sched_yield(); > > > > > > cnt++; > > > > > > } else { > > > > > > tm.tv_sec = 0; > > > > > > tm.tv_nsec = 2000001; > > > > > > nanosleep(&tm, ((void *)0)); > > > > > > cnt = 0; > > > > > > } > > > > > > } > > > > *shudder* that is quite horrible. > > > > > > > > This means all your 'atomics' are broken for anything SCHED_FIFO and the > > > > like. You simply _cannot_ run a realtime system. > > > The code above is from uClibc old threading library which we don't use anymore. > > > The NPTL version doesn't have all of this song-n-dance and relies on futexes. The > > > change we are talking about is only for the atomics in perf itself. I do > > > understand your POV though. > > > > > > > (also, for ACQUIRE you want the READ_MEMORY_BARRIER() _after_ the > > > > test-and-set control dependency.) > > > Absolutely and in this case it will have to be added both inside the loop and one > > > at the end to cover both the scenarios ! > > > > > I'm wondering what are our plans for now? > > Are we going to accept proposed fix just for ARC in 4.4 (and to all stables then) > > or we'll try to come up with more general solution? > > I agree with the current solution to add -atomic to for arc700 builds. > Although making that default for arc700 tools will be better but that will not fix > things before next release of tools etc. > > But we *do* need to improve generic solution > 1. Add atomics detection in perf to add fall back arch stubs > 2. ARC needs to add syscall for facilitating atomic r-m-w ! So the most recent ARC GNU tools (2015.12) were just released yesterday and still atomics are disabled by default for ARCv1. That means perf will continue to fail on building for now. Do you think we may apply my initial fix to 4.5 while it is in development and then to stable trees as well? -Alexey