Calling clock_gettime very often with rr

Robert O'Callahan robert at ocallahan.org
Mon May 28 12:37:37 UTC 2018


On Mon, May 28, 2018 at 8:34 PM, Benjamin King <benjaminking at web.de> wrote:

> I'm searching for a solution for this:
> --- snip ---
> // Build: 'gcc -O0 main.c -o 50m_clock_gettime'
> // Test1: 'time ./50m_clock_gettime' -> ~1s
> // Test2: 'time rr ./50m_clock_gettime' -> ~26s
> #include <time.h>
> int main()
> {
>   struct timespec tp;
>   for ( int i = 50e6; i; --i )
>     clock_gettime( CLOCK_REALTIME, &tp );
> }
>
> --- snip ---
>
> Minimal example, but in a tracer I wrote, I'm calling clock_gettime very
> often.
> I suppose this is slower in rr because the call to __vsdo_clock_gettime
> needs to be dealt with.
>
> Is there some other way to get wall clock time that is more efficient when
> running under rr?
> I need approximately microsecond resolution.
>

The majority of the overhead here is that our clock_gettime wrapper can't
use the VDSO version, it has to make an actual syscall. This is because the
VDSO clock_gettime reads values from memory shared with the kernel; the
results are by nature nondeterministic in a way that would break rr. I
don't think there's a way around this for clock_gettime. I suppose with
some very clever hacking it might be possible to reimplement the VDSO
clock_gettime in such a way that we log enough information to replay it
correctly, but it would have to be pretty clever ... keep in mind that the
control flow during replay must match the control flow during recording.

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, and your testcase is doing about 2 clock_gettimes per
microsecond under rr, which means I guess the overhead on your actual
workload shouldn't be much more than 2x?

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20180529/6997584d/attachment.html>


More information about the rr-dev mailing list