Calling clock_gettime very often with rr

Benjamin King benjaminking at
Mon May 28 17:38:10 UTC 2018

Hi Rob,

On Tue, May 29, 2018 at 12:37:37AM +1200, Robert O'Callahan wrote:
> >      struct timespec tp;
> >      for ( int i = 50e6; i; --i )
> >        clock_gettime( CLOCK_REALTIME, &tp );
> [...]
>Unfortunately I can't think of any other way to get a time value in way that
>works with rr and doesn't require a system call.
>What's the overhead on your actual workload? If you only need microsecond
>resolution then I assume the minimum time between clock_gettimes is one
>microsecond, [...]

My tracer calls clock_gettime on all function entries/exits. When the
duration of a function is mostly <1ms, this instrumentation is dynamically
replaced by nop's. This in turn reduces the duration of parent functions
until instrumentation is also patched out there. This ends when no frequent
calls to very short functions remain.

In this state your analysis holds and there are no more than 2 million calls
per second to clock_gettime. 

I think that fewer functions benefit from that dynamic patching when running
under rr, making the program slower.

I was considering using rdtsc to avoid too frequent calls to clock_gettime.
Something along the lines of 'assume that 1 microsecond did not pass unless
time stamp counter changed by at least X'. But this is also nondeterminism
that would need to be tracked by rr, no?

Alternatively, I could patch out instrumentation for slower functions when
running with rr, say functions running in less than 10ms. Not ideal, but
might work.


More information about the rr-dev mailing list