From: Thomas Gleixner <tglx@linutronix.de>
To: Linux <zhaoyan.liao@linux.alibaba.com>
Cc: mingo@redhat.com, hpa@zytor.com, dwmw@amazon.co.uk,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
songmuchun@bytedance.com, likunkun@bytedance.com,
guancheng.rjk@alibaba-inc.com, duanxiongchun@bytedance.com,
wenan.mao@linux.alibaba.com
Subject: Re: [PATCH] use 64bit timer for hpet
Date: Thu, 08 Jul 2021 13:17:14 +0200 [thread overview]
Message-ID: <87o8bdoy11.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <8A96C0F7-FBE4-4B23-8565-E814401BF927@linux.alibaba.com>
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.
next prev parent reply other threads:[~2021-07-08 11:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 8:13 [PATCH] use 64bit timer for hpet zhaoyan.liao
2021-07-02 15:57 ` kernel test robot
2021-07-07 10:04 ` Thomas Gleixner
2021-07-08 3:11 ` Linux
2021-07-08 11:17 ` Thomas Gleixner [this message]
2021-07-12 4:52 ` Linux
2021-07-12 7:25 ` Thomas Gleixner
2021-07-13 1:43 ` Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o8bdoy11.ffs@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=duanxiongchun@bytedance.com \
--cc=dwmw@amazon.co.uk \
--cc=guancheng.rjk@alibaba-inc.com \
--cc=hpa@zytor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=likunkun@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=songmuchun@bytedance.com \
--cc=wenan.mao@linux.alibaba.com \
--cc=zhaoyan.liao@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).