Re: Weird clock behaviour with current (amd64) kernel

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sun, Aug 14, 2022 at 09:00:20AM +0700, Robert Elz wrote:
>     Date:        Sun, 14 Aug 2022 00:28:38 +0200
>     From:        Joerg Sonnenberger <joerg%bec.de@localhost>
>     Message-ID:  <YvgllnAXjXt6afcR%bec.de@localhost>
> 
>   | I'm more wondering about the LAPIC frequency here. That one is normally
>   | used to drive the clockintr and if that frequency is off, interrupt rate
>   | would be off too. Does the interrupt rate match HZ?
> 
> That's a very good question, I never thought to check that, and should have.
> I will do later today, when I also test Michael's latest patch for HPET
> overflow.
> 
> Thanks both.
> 
> Do you (either of you, or anyone else) consider that what is happening
> here might be related to PR 43997?  If it is, then this might not be
> quite so unimportant as I had been considering it.


PR 43997 is more of a bug in qemu than anything else. You cannot emulate
a 100Hz interrupt when your clock granularity for sleep is 10ms. Best you
can do is to catch up interrupts when you are too late but which has other
problems. Qemu doesn't catch up, and so the emulated interrupt effectively
runs at 50Hz.

Linux (tickless kernel) has a clock granularity of ideally zero (in reality
limited by clock resolution and CPU speed), so you don't see such a problem
there.

You can still get a discrepancy between sleep time and wall clock
time as these clocks run independently (starting with the fact that
you sleep for "at least" some interval), but that's a different problem.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."