From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758720AbbJ3GUu (ORCPT ); Fri, 30 Oct 2015 02:20:50 -0400 Received: from smtprelay.synopsys.com ([198.182.47.9]:51708 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758525AbbJ3GT0 convert rfc822-to-8bit (ORCPT ); Fri, 30 Oct 2015 02:19:26 -0400 From: Vineet Gupta To: Alexey Brodkin 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: AQHRCjH5qUIZ06l560WdnGKbYbcPAw== Date: Fri, 30 Oct 2015 06:19:21 +0000 Message-ID: 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> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.197.182] 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 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 ! -Vineet