Resend in plain text mode.
On Wed, Jul 27, 2016 at 9:07 AM, Xinliang David Li wrote:
> Our experience is that non-atomic counter update (the current
> implementation) rarely result in corrupted profile (in heavily threaded
> environment) -- it usually results in some profile insanity which can be
On 07/26/2016 01:15 AM, Andi Kleen wrote:
> You definitely need a new flag: atomic or per thread instrumentation
> will almost certainly have significant overhead (either at run time
> or in memory). Just making an existing facility a lot of slower
> without a way around it is not a good idea.
Hi
Martin Liška writes:
>
> I'm also surprised about it :) Let's start without invention of a new flag,
> I'll work on that.
You definitely need a new flag: atomic or per thread instrumentation
will almost certainly have significant overhead (either at run time
or in memory). Just making an existin
On 07/25/16 08:46, Richard Biener wrote:
There is also the question about optimization - we go great lengths to ensure
that for example loop store motion applies to counter updates so we get
old_ctr = values[42];
for (;;)
...
values[42] = old_ctr + # iterations
using atomics there might s
On Mon, Jul 25, 2016 at 2:35 PM, Nathan Sidwell wrote:
> On 07/25/16 08:28, Martin Liška wrote:
>
>> I'm also surprised about it :) Let's start without invention of a new
>> flag, I'll work on that.
>
>
> As using atomic add doesn't result in a change to the libgcov interface or
> structures, that
On 07/25/16 08:28, Martin Liška wrote:
I'm also surprised about it :) Let's start without invention of a new flag,
I'll work on that.
As using atomic add doesn't result in a change to the libgcov interface or
structures, that's probably the best first approach. (It also probably gets the
9
On 07/25/2016 02:06 PM, Nathan Sidwell wrote:
> On 07/25/16 04:14, Martin Liška wrote:
>> Hello.
>>
>> I've just analyzed PR68080, which exposes 2 interesting problems we have:
>>
>> 1) Majority of instrumented profiling code is not thread-safe, for instance
>> edge profiler:
>>
>> PROF_edge_cou
On 07/25/16 08:14, Richard Biener wrote:
There's pthread_detach () - do we wrap that appropriately? That said, another
way to make counters thread-safe is to allocate per-thread counters and update
those (for example by making the counters __TLS). The interesting part is then
to merge them wit
On Mon, Jul 25, 2016 at 2:06 PM, Nathan Sidwell wrote:
> On 07/25/16 04:14, Martin Liška wrote:
>>
>> Hello.
>>
>> I've just analyzed PR68080, which exposes 2 interesting problems we have:
>>
>> 1) Majority of instrumented profiling code is not thread-safe, for
>> instance edge profiler:
>>
>> P
On 07/25/16 04:14, Martin Liška wrote:
Hello.
I've just analyzed PR68080, which exposes 2 interesting problems we have:
1) Majority of instrumented profiling code is not thread-safe, for instance
edge profiler:
PROF_edge_counter_11 = __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0];
Hello.
I've just analyzed PR68080, which exposes 2 interesting problems we have:
1) Majority of instrumented profiling code is not thread-safe, for instance
edge profiler:
PROF_edge_counter_11 = __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0];
PROF_edge_counter_12 = PROF_edge_counter
11 matches
Mail list logo
