lkml.org 
[lkml]   [2021]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] use 64bit timer for hpet
Date
Liao!

On Thu, Jul 08 2021 at 11:11, Linux wrote:
>> 2021年7月7日 下午6:04,Thomas Gleixner <tglx@linutronix.de> 写道:
>> 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.

\
 
 \ /
  Last update: 2021-07-08 13:18    [W:0.078 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site