linux-kernel - Re: [PATCH] use 64bit timer for hpet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Jul 2021 12:52:36 +0800
From:   Linux <zhaoyan.liao@...ux.alibaba.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     mingo@...hat.com, hpa@...or.com, dwmw@...zon.co.uk,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        songmuchun@...edance.com, likunkun@...edance.com,
        guancheng.rjk@...baba-inc.com, duanxiongchun@...edance.com,
        wenan.mao@...ux.alibaba.com
Subject: Re: [PATCH] use 64bit timer for hpet

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