[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075F44CE67A@IN01WEMBXA.internal.synopsys.com>
Date: Fri, 30 Oct 2015 06:19:21 +0000
From: Vineet Gupta <Vineet.Gupta1@...opsys.com>
To: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"andi@...stfloor.org" <andi@...stfloor.org>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
"acme@...hat.com" <acme@...hat.com>,
"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
"giladb@...hip.com" <giladb@...hip.com>,
"dsahern@...il.com" <dsahern@...il.com>,
"dvhart@...ux.intel.com" <dvhart@...ux.intel.com>,
"noamc@...hip.com" <noamc@...hip.com>
Subject: Re: [RFC] perf: fix building for ARCv1
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists