Liao,
On Fri, Jul 02 2021 at 16:13, zhaoyan liao wrote:
> The kernel judges whether the tsc clock is accurate in the
> clocksource_watchdog background thread function. The hpet clock source
> is 32-bit, but tsc is 64-bit. Therefore, when the system is busy and the
> clocksource_watchdog cannot be scheduled in time, the hpet clock may
> overflow and cause the system to misjudge tsc as unreliable.
Seriously? The wrap-around time for 32bit HPET @24MHz is ~3 minutes.
> In this case, we recommend that the kernel adopts the 64-bit hpet clock
> by default to keep the width of the two clock sources the same to reduce
> misjudgment. Some CPU models may not support 64-bit hpet, but according
> to the description of the CPU's register manual, it does not affect our
> reading action.
So much for the theory.
> -#define HPET_MASK CLOCKSOURCE_MASK(32)
> +#define HPET_MASK CLOCKSOURCE_MASK(64)
How is that valid for a 32bit HPET? This breaks the clocksource.
> +inline unsigned long hpet_readq(unsigned int a)
> +{
> + return readq(hpet_virt_address + a);
Breaks 32bit build immediately.
Aside of that the reason why the kernel does not support 64bit HPET is
that there are HPETs which advertise 64bit support, but the
implementation is buggy.
IOW, while this works for your hardware this breaks quite some parts of
the universe. Not really a good approach.
Thanks,
tglx
