Taylor R Campbell <riastr...@netbsd.org> writes:
>> Date: Thu, 27 Jul 2023 11:17:30 -0400
>> From: Brad Spencer <b...@anduin.eldar.org>
>>
>> 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(@) }'
The first one errors for me:
# cat d3a
#!/bin/sh
dtrace -x nolibs -n 'sdt:xen:hardclock:jump { @ = quantize(arg1 - arg0) }
tick-10s { printa(@) }'
# ./d3a
dtrace: invalid probe specifier sdt:xen:hardclock:jump { @ = quantize(arg1 -
arg0) } tick-10s { printa(@) }: probe description :::tick-10s does not match
any probes
with
$NetBSD: xen_clock.c,v 1.15 2023/07/28 10:39:14 riastradh Exp $
I updated nothing else other than xen_clock.c and rebuilt the kernel and
booted it.
> dtrace -x nolibs -n 'sdt:xen:hardclock:jump /arg2 >= 430/ {
> printf("TIMECOUNTER BAD: hardclock delayed by %d ns (%d tick)", arg1 - arg0,
> arg2) }'
This one executed.
> 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'.)
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
