Gleixner,
> Sorry, keeping the softirq from running for 3 minutes is simply out of
> spec. If the sysadmin decides to do so, then he can keep the pieces.
It is because the kernel thread is busy that the clocksource_watchdog
thread is not scheduled, not softirq.
> 4) For any system which actually has to use HPET the 64bit HPET is
> overhead. HPET access is slow enough already.
I agree with your opinion. If it is unreasonable to use a 64-bit HPET timer,
is there any other more reasonable method to avoid misjudgment of the
tsc clock?
I will also try to switch to other methods.
Thanks
Zhaoyan Liao
> 2021年7月8日 下午7:17，Thomas Gleixner <tglx@xxxxxxxxxxxxx> 写道：
>
> Liao!
>
> On Thu, Jul 08 2021 at 11:11, Linux wrote:
>>> 2021年7月7日 下午6:04，Thomas Gleixner <tglx@xxxxxxxxxxxxx> 写道：
>>> Seriously? The wrap-around time for 32bit HPET @24MHz is ~3 minutes.
>>
>> In some cases, our system will be very busy, and the timeout of 3 minutes
>> is not an exaggeration. Then, the system considers that the tsc clock is
>> inaccurate and switches the tsc clock to the hpet clock, which brings
>> greater performance overhead.
>
> Sorry, keeping the softirq from running for 3 minutes is simply out of
> spec. If the sysadmin decides to do so, then he can keep the pieces.
>
>>> 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.
>>
>> Can you tell me what is the buggy with the 64-bit hpet clock?
>
> I forgot the details, but when I tried moving HPET to 64bit it did not
> work on one of my machines due to an erratum and other people reported
> similar issues on different CPUs/chipsets.
>
> TBH, I'm not interested at all to chase down these buggy implementations
> and have yet another pile of quirks.
>
>> In my opinion, it is unreasonable to use a lower-bit width clock to
>> calibrate a higher-bit width clock, and the hardware already supports
>> the higher-bit width.
>
> There is nothing unreasonable with that, really:
>
> 1) This is not about calibration. It's a sanity check to catch
> broken TSC implementations.
>
> Aside of that it _IS_ very reasonable for calibration. We even
> calibrate TSC via the PIT if we can't get the frequency from
> the firmware.
>
> 2) Expecting that the softirq runs within 3 minutes is very
> reasonable.
>
> 3) On modern machines this is usually not longer necessary. If you
> are confident that the TSC on your system is stable then you
> can disable the watchdog via the kernel command line.
>
> There is also effort underway to come up with reasonable
> conditions to avoid the watchdog on those CPUs in the first place.
>
> 4) For any system which actually has to use HPET the 64bit HPET is
> overhead. HPET access is slow enough already.
>
> 5) 32bit HPET has to be supported as well and just claiming that a
> 64bit access on 32bit HPET does not matter is just wishful
> thinking. Aside of breaking 32bit kernels along the way which
> is just a NONO.
>
> #4 and #5 were the main reason why I gave up on it - aside of the
> discovery that there are broken implementations out there.
>
> So no, there is really no compelling reason to support 64bit HPETs.
>
> Thanks,
>
> tglx
> ---
> P.S: Please trim your replies.
