From: yanghui <yanghui.def@bytedance.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Stephen Boyd <sboyd@kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH] Clocksource: Avoid misjudgment of clocksource
Date: Sat, 9 Oct 2021 11:22:48 +0800 [thread overview]
Message-ID: <665f749e-b71e-a793-d759-87f7cf89677c@bytedance.com> (raw)
In-Reply-To: <CALAqxLWUNFozhfhuVFAPo9xGgO+xsXPQ=i5w1Y0E9-w-PdHXgw@mail.gmail.com>
在 2021/10/9 上午7:45, John Stultz 写道:
> On Fri, Oct 8, 2021 at 1:03 AM yanghui <yanghui.def@bytedance.com> wrote:
>>
>> clocksource_watchdog is executed every WATCHDOG_INTERVAL(0.5s) by
>> Timer. But sometimes system is very busy and the Timer cannot be
>> executed in 0.5sec. For example,if clocksource_watchdog be executed
>> after 10sec, the calculated value of abs(cs_nsec - wd_nsec) will
>> be enlarged. Then the current clocksource will be misjudged as
>> unstable. So we add conditions to prevent the clocksource from
>> being misjudged.
>>
>> Signed-off-by: yanghui <yanghui.def@bytedance.com>
>> ---
>> kernel/time/clocksource.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
>> index b8a14d2fb5ba..d535beadcbc8 100644
>> --- a/kernel/time/clocksource.c
>> +++ b/kernel/time/clocksource.c
>> @@ -136,8 +136,10 @@ static void __clocksource_change_rating(struct clocksource *cs, int rating);
>>
>> /*
>> * Interval: 0.5sec.
>> + * MaxInterval: 1s.
>> */
>> #define WATCHDOG_INTERVAL (HZ >> 1)
>> +#define WATCHDOG_MAX_INTERVAL_NS (NSEC_PER_SEC)
>>
>> static void clocksource_watchdog_work(struct work_struct *work)
>> {
>> @@ -404,7 +406,9 @@ static void clocksource_watchdog(struct timer_list *unused)
>>
>> /* Check the deviation from the watchdog clocksource. */
>> md = cs->uncertainty_margin + watchdog->uncertainty_margin;
>> - if (abs(cs_nsec - wd_nsec) > md) {
>> + if ((abs(cs_nsec - wd_nsec) > md) &&
>> + cs_nsec < WATCHDOG_MAX_INTERVAL_NS &&
>
> Sorry, it's been awhile since I looked at this code, but why are you
> bounding the clocksource delta here?
> It seems like if the clocksource being watched was very wrong (with a
> delta larger than the MAX_INTERVAL_NS), we'd want to throw it out.
>
>> + wd_nsec < WATCHDOG_MAX_INTERVAL_NS) {
>
> Bounding the watchdog interval on the check does seem reasonable.
> Though one may want to keep track that if we are seeing too many of
> these delayed watchdog checks we provide some feedback via dmesg.
Yes, only to check watchdog delta is more reasonable.
I think Only have dmesg is not enough, because if tsc was be misjudged
as unstable then switch to hpet. And hpet is very expensive for
performance, so if we want to switch to tsc the only way is to reboot
the server. We need to prevent the switching of the clock source in
case of misjudgment.
Circumstances of misjudgment:
if clocksource_watchdog is executed after 10sec, the value of wd_delta
and cs_delta also be about 10sec, also the value of (cs_nsec- wd_nsec)
will be magnified 20 times(10sec/0.5sec).The delta value is magnified.
But now clocksource is accurate, the Timer is inaccurate. So we
misjudged the clocksource. We need avoid this from happening.
thanks
-Hui
>
> thanks
> -john
>
next prev parent reply other threads:[~2021-10-09 3:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-08 8:03 yanghui
2021-10-08 23:45 ` John Stultz
2021-10-09 3:22 ` yanghui [this message]
2021-10-09 3:38 ` [External] " John Stultz
2021-10-09 9:02 ` yanghui
2021-10-12 5:02 ` John Stultz
2021-10-18 10:41 ` yanghui
2021-10-09 14:04 ` brookxu
2021-10-12 4:52 ` John Stultz
2021-10-12 5:21 ` brookxu
2021-10-12 5:29 ` John Stultz
2021-10-12 8:06 ` brookxu
2021-10-14 7:03 ` yanghui
2021-10-15 6:56 ` yanghui
2021-10-15 7:24 ` brookxu
2021-10-18 16:14 ` John Stultz
2021-10-19 4:14 ` yanghui
2021-10-19 5:00 ` John Stultz
2021-10-20 10:09 ` Luming Yu
2021-10-20 17:49 ` Paul E. McKenney
2021-10-21 9:37 ` Luming Yu
2021-10-22 23:36 ` Paul E. McKenney
2021-11-01 9:59 ` Luming Yu
2021-11-01 16:57 ` Paul E. McKenney
2021-11-03 8:27 ` Luming Yu
2021-11-03 15:54 ` Paul E. McKenney
2021-11-04 10:56 ` Luming Yu
2021-12-09 13:14 ` Gang Li
2021-12-09 16:44 ` Paul E. McKenney
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=665f749e-b71e-a793-d759-87f7cf89677c@bytedance.com \
--to=yanghui.def@bytedance.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®