This is the mail archive of the
mailing list for the GCC project.
Re: Thread-safety of a profiled binary (and GCOV runtime library)
Resend in plain text mode.
On Wed, Jul 27, 2016 at 9:07 AM, Xinliang David Li <firstname.lastname@example.org> 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
> corrected with -fprofile-correction -- otherwise we would have been forced
> to go the TLS route.
> The profile corruption usually happens when server program crashed during
> dumping (server program usually do not exit, so forcing it to exit to dump
> profile can cause problem). Our solution is to introduce profile runtime API
> to be invoked by the user.
> We added the atomic support mostly for linux kernel FDO. The support is in
> google/gcc_49 branch. The option description is:
> ; fprofile-generate-atomic=0: disable aotimically update.
> ; fprofile-generate-atomic=1: aotimically update edge profile counters.
> ; fprofile-generate-atomic=2: aotimically update value profile counters.
> ; fprofile-generate-atomic=3: aotimically update edge and value profile
> ; other values will be ignored (fall back to the default of 0).
> Common Joined UInteger Report Var(flag_profile_gen_atomic) Init(0)
> fprofile-generate-atomic=[0..3] Atomically increments for profile counters.
> On Wed, Jul 27, 2016 at 5:05 AM, Martin Liška <email@example.com> wrote:
>> 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.
>> Agree with that!
>> > BTW iirc there were patches from google on this a few years back.
>> > May be still in some branch.
>> That's great, I'm CCing Google people who worked on PGO, hope they will
>> help me to find patches/discussion about the problem.
>> > -Andi