> Date: Thu, 27 Jul 2023 11:17:30 -0400
> From: Brad Spencer <[email protected]>
>
> On the system that I have that exhibits the negative runtime problem, it
> may very well be the case that hardclocks are missed for 4.3sec. The
> system has to have been up for a while and busy as a prereq., but if I
> then run:
>
> dtrace -x nolibs -n 'sdt:xen:clock:, sdt:xen:hardclock:, sdt:xen:timecounter:
> { printf("%d %d %d %d %d %d %d %d", arg0, arg1, arg2, arg3, arg4, arg5, arg6,
> arg7) }'
Update xen_clock.c, and try this now (one in each of two terminals):
dtrace -x nolibs -n 'sdt:xen:hardclock:jump { @ = quantize(arg1 - arg0) }
tick-10s { printa(@) }'
dtrace -x nolibs -n 'sdt:xen:hardclock:jump /arg2 >= 430/ { printf("TIMECOUNTER
BAD: hardclock delayed by %d ns (%d tick)", arg1 - arg0, arg2) }'
Let it run for a while until the second one fires, or until you get
bored, then share the last histogram from the first one?
(Note: I added a probe sdt:xen:hardclock:tick which fires on every
tick, so the original dtrace script will be a little too noisy. If
you want to do it again for some reason, narrow the scope from
`sdt:xen:hardclock:' to just `sdt:xen:hardclock:missed,
sdt:xen:hardclock:jump'.)
