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.