Re: Understanding PR kern/43997 (kernel timing problems / qemu)

[Frank Kardel <kardel%kardel.name@localhost>]

Could you check which timecounter is used under qemu?

sysctl kern.timecounter.hardware

Usually the timecounters are hardware-based and have no relation
to the clockinterrupt. In case of qemu you might get a good
emulated timecounter, but a suboptimal clockinterupt.
If this is the case it helps to use the clockinterrupt
itself as timecounter for the wall clock time to avoid a discrepancy 
between clockinterrupt-driven timeout handling and wall-clock time tracking.

sysctl -w kern.timecounter.hardware=clockinterrupt

This is the opposite from deducing the missed clock interrupts
from the wall clock time and keeps timeout handling and in the emulation 
observed wall-time synchronized no matter how slow
the clock-interrupts are - the emulated wall clock time will be
at the same rate.

This might be a workaround for the current qemu issue and does not
affect any discussion about improving sleep timing or
migrating to a tick-less kernel.

BTW: even a tick-less kernel will need to e a minimum interrupt
frequency in order to avoid undetected timecounter wrapping.

Frank



On 07/30/17 14:22, Robert Elz wrote:
>      Date:        Sun, 30 Jul 2017 13:01:50 +0300
>      From:        Andreas Gustafsson <gson%gson.org@localhost>
>      Message-ID:  <22909.44686.188004.117151%guava.gson.org@localhost>
>
>    | I don't think the slowness of qemu's emulation is the actual cause of
>    | its inability to simulate clock interrupts at 100 Hz.
>
> Yes, I was wondering about that, as if it was, there'd often be no time
> left for anything else...
>
>    | If my theory is correct, there are at least three ways the problem
>    | could be fixed:
>    |
>    |  - Improve the time resolution of sleeps on the host system,
>    |  - Make qemu deal better with hosts unable to sleep for short periods
>
> Either, or both, of those should be fixed, and I might get to take a
> look at the first one (the insides of qemu are not all that appealing...)
> but
>
>    |  - Make the guest system deal better with missed timer interrupts.
>
> This one needs to be fixed. an idle system that says it takes 13 seconds
> to do a sleep 10 is simply broken.  Fixing the other issues (or either
> one of them) would make it much harder to work on this one - that is
> keeping the qemu/host relationship stable allows a platform where the
> timekeeping issues in the kernel are known to occur, so a good way to
> verify any fix, so I think this should be fixed first.
>
> kre