Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1381942

Re: [RFC 2/2] time: double check if watchdog clocksource is correct

Path csiph.com!aioe.org!news.servidellagleba.it!bofh.it!news.nic.it!robomod
From John Stultz <john.stultz@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFC 2/2] time: double check if watchdog clocksource is correct
Date Mon, 18 Apr 2016 19:40:02 +0200
Message-ID <rpljs-Zc-7@gated-at.bofh.it> (permalink)
References <rmUQq-6Fz-3@gated-at.bofh.it> <rmUQq-6Fz-1@gated-at.bofh.it>
X-Original-To Shaohua Li <shli@fb.com>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vM9gyJQHJ7xMrY2QzKoqUyzp3HGz9jgVRTw1olZfLsE=; b=S7EroBGpmIzxkLd++ypF6DmOoXR6yp6YbOyUBzoBI3IbtTbS4mdj/ZjJg5ZmshSAYf NLmG63CHxLln3Q3wAZK4JJP7OEgJW3hMWFHPMt3gctUu0+pf77xsRwibETi5kj4ZKVdp FTxp13j1RwKtG7YII8yaD6+o8aspmDCBOl/pI=
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vM9gyJQHJ7xMrY2QzKoqUyzp3HGz9jgVRTw1olZfLsE=; b=BLqr5ngORxYDJ9UTxwk2TKcKI/zSjijCLpFdM8Vr802aGoCqSVc2BEDlO4fkdUsAzj yaf7ltI3K3Ilf9GTYN31D3jQaIjRsDZ4iGy+YqUHoeXS6lpkwaVvt+i5fCO284jOJbIf pM4C3RF1b8PtYk3mle/YZ5btZjdcwz0rU04nAaWIaHgyZYcLG8dbP2OSn5jzrviziX4d XG2uCSIVoRw7mQfpiH8yp/l3PMZwI8oKL9sta2lmINzjkNEW1T+ql97O4gcyxI7uPkkl 2h4VHDRZlEPvqpsJkI3YQcH4gNinaer3X4hC8cUBKeb4KSusrNcoUxWoVbjUvZj3mPxl ydqw==
X-Gm-Message-State AOPr4FVn5P7tSjjLBg+0/JYlNBo8YTnNqIMeuDwBBZMMhiMGXp1Y8UCP/nt6qCJsPyrYWXV6qRmKRC8BwLVKkpxZ
MIME-Version 1.0
X-Received by 10.202.87.143 with SMTP id l137mr16166723oib.89.1461000669368; Mon, 18 Apr 2016 10:31:09 -0700 (PDT)
Content-Type text/plain; charset=UTF-8
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 76
Organization linux.* mail to news gateway
X-Original-Cc lkml <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, calvinowens@fb.com, Gratian Crisan <gratian.crisan@ni.com>
X-Original-Date Mon, 18 Apr 2016 10:31:09 -0700
X-Original-Message-ID <CALAqxLV7RbewzJjP2uXsFjkmgeWiuzAayxbjj0gGMdBw3KT-ng@mail.gmail.com>
X-Original-References <09c4f19409012995595db6fd0a12f326c292af1a.1460422356.git.shli@fb.com> <984ee7ee5ba91bdaa155a16e741f5b83d70233d2.1460422356.git.shli@fb.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1381942

Show key headers only | View raw


On Mon, Apr 11, 2016 at 5:57 PM, Shaohua Li <shli@fb.com> wrote:
> We use watchdog clocksource to detect unstable clocksource. This assumes
> watchdog clocksource is correct. But it's possible watchdog clocksource
> is crappy, please see previous patch. Double check if watchdog interval
> is too long and bypass potential wrong watchdog clocksource.
>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
>  kernel/time/clocksource.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index 56ece14..36aff4e 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -122,9 +122,10 @@ static int clocksource_watchdog_kthread(void *data);
>  static void __clocksource_change_rating(struct clocksource *cs, int rating);
>
>  /*
> - * Interval: 0.5sec Threshold: 0.0625s
> + * Interval: 0.5sec, Max Interval: 0.75sec, Threshold: 0.0625s
>   */
>  #define WATCHDOG_INTERVAL (HZ >> 1)
> +#define WATCHDOG_MAX_INTERVAL ((NSEC_PER_SEC >> 1) + (NSEC_PER_SEC >> 2))

Is there a reason this #define is so obtusely stated? Its all going to
be pre-computed by the compiler, so I'm not sure why to make it more
opaque to the casual reader.  Maybe something more like:
(750*MSEC_PER_SEC)

>  #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
>
>  static void clocksource_watchdog_work(struct work_struct *work)
> @@ -217,7 +218,8 @@ static void clocksource_watchdog(unsigned long data)
>                         continue;
>
>                 /* Check the deviation from the watchdog clocksource. */
> -               if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) {
> +               if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD &&
> +                   wd_nsec < WATCHDOG_MAX_INTERVAL) {
>                         pr_warn("timekeeping watchdog on CPU%d: Marking clocksource '%s' as unstable because the skew is too large:\n",
>                                 smp_processor_id(), cs->name);
>                         pr_warn("                      '%s' wd_now: %llx wd_last: %llx mask: %llx\n",
> --


My main concern with these tweaks have been that we might have a case
where there's a slow TSC (old cpufreq effected style, or maybe halts
in deep idle),  so everything is moving slowly and the timers are
firing late. Then the watchdog interval would *look* to be too long
and we wouldn't have a good tool for disqualifying that bad TSC.

That said, I am continuing to hear cases of problematic watchdog
disqualifications where the watchdog is to blame, due to wraparound
caused by VM delays, PREEMPT_RT, or softirq processing, so something
here would be nice.

Gratin (cc'ed) also was looking at this, and we had some thoughts
about trying to avoid the watchdog wrap-around issue by checking that
the clocksource's counter divided by the watchdog wraparound interval
(in nsecs)  matched the watchdog's counter (again, in nsecs).

But it seems like for your case where the watchdog hardware is bad,
that still wouldn't catch it. Something like a watchdog watchdog w/
something like the RTC might be an approach, but I worry that we will
hit the same problematic "can't trust the RTC on hardware foo" issue
down the road.  Having a watchdog quorum between multiple counters
might be the only way there, but on many devices there's really only
two main options. :/

Thomas: Any other thoughts? Are these just oddball cases that have to
be dealt with via tsc=reliable boot arguments? Should we print
something informative about that option when we disqualify the TSC?

thanks
-john

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

Re: [RFC 2/2] time: double check if watchdog clocksource is correct John Stultz <john.stultz@linaro.org> - 2016-04-18 19:40 +0200

csiph-web