On 10/19/2015 02:35 AM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:28:43AM +, 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 b
On Friday 05 February 2016 09:40 PM, a...@redhat.com wrote:
> Em Fri, Feb 05, 2016 at 11:18:52AM +, Noam Camus escreveu:
>> Well here for EZchip I also see the:
>> undefined reference to `__sync_add_and_fetch_4'
>> undefined reference to `__sync_sub_and_fetch_4'
>
> Yeah, because there is no:
>From: Vineet Gupta
>Sent: Thursday, February 4, 2016 6:13 AM
>Noam, what's the atomic story for EZChip. Do you support such things for user
space in GNU tools. If -atomic is added to perf user space builds are you guys
OK!
Well here for EZchip I also s
+CC Noam
On Wednesday 03 February 2016 09:50 PM, Alexey Brodkin wrote:
>> 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.
>> >
>> > Bu
Hi Vineet,
On Fri, 2015-10-30 at 06:19 +, Vineet Gupta wrote:
> On Thursday 29 October 2015 09:28 PM, Alexey Brodkin wrote:
> > Hi Vineet,
> >
> > On Tue, 2015-10-20 at 10:45 +, Vineet Gupta wrote:
> > > On Tuesday 20 October 2015 03:41 PM, Peter Zijlstra wrote:
> > > > > > Can we use exi
On Saturday 17 October 2015 07:06 PM, Alexey Brodkin wrote:
> Perf uses atomic options and so it is required to have atomics enabled
> in toolchain.
>
> In case of ARC atomics are enabled by default for ARCv2 but disabled for
> ARCv1. Now we explicitly enable atomics for either ARC achitecture
> ve
On Thursday 29 October 2015 09:28 PM, Alexey Brodkin wrote:
> Hi Vineet,
>
> On Tue, 2015-10-20 at 10:45 +, 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
Hi Vineet,
On Tue, 2015-10-20 at 10:45 +, 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 * sp
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_MEMO
On Tue, Oct 20, 2015 at 08:00:46AM +, Vineet Gupta wrote:
> On Monday 19 October 2015 03:22 PM, Peter Zijlstra wrote:
> > On Mon, Oct 19, 2015 at 09:46:35AM +, Vineet Gupta wrote:
> >> On ARC we could use the atomic EXchange to implement a user space only
> >> binary
> >> semaphore - these
On Monday 19 October 2015 03:22 PM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:46:35AM +, Vineet Gupta wrote:
>> 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
>> lit
On Monday 19 October 2015 03:22 PM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:46:35AM +, Vineet Gupta wrote:
>> > 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
On Mon, Oct 19, 2015 at 09:46:35AM +, Vineet Gupta wrote:
> 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 a
On Monday 19 October 2015 03:05 PM, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:28:43AM +, 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
> >> si
On Mon, Oct 19, 2015 at 09:28:43AM +, 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
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
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.
Also perf is now multi threaded to some degree.
-Andi
--
To unsubscribe from this list: se
On Monday 19 October 2015 04:45 AM, Andi Kleen wrote:
> Alexey Brodkin writes:
>> So the best we may do is to implement detection of atomics in the toolchain
>> and if there's no atomics hard stop with
>> perf building.
> If your target is single cpu only you can always simulate them in C.
>
> -A
Alexey Brodkin writes:
>
> So the best we may do is to implement detection of atomics in the toolchain
> and if there's no atomics hard stop with
> perf building.
If your target is single cpu only you can always simulate them in C.
-Andi
--
To unsubscribe from this list: send the line "unsubscr
Hi Vineet,
Looks like this time atomics are a must. And that really sucks!
See these commits that introduce usage of atomic_xxx() all around the perf and
tools it uses:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f812d3045c2385ac16237e68b156859c4005526e
http://git.k
On Saturday 17 October 2015 07:06 PM, Alexey Brodkin wrote:
> Perf uses atomic options and so it is required to have atomics enabled
> in toolchain.
>
> In case of ARC atomics are enabled by default for ARCv2 but disabled for
> ARCv1. Now we explicitly enable atomics for either ARC achitecture
> ve
21 matches
Mail list logo
