Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2831298pxb; Fri, 8 Oct 2021 16:46:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC8XIMtaqkqklQn7rAKkkvWiTjqcESljQPBoSKRQNP5hJ6V4v94D+G40y3Uw74HCevjInn X-Received: by 2002:a17:906:a404:: with SMTP id l4mr7883367ejz.175.1633736817409; Fri, 08 Oct 2021 16:46:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633736817; cv=none; d=google.com; s=arc-20160816; b=w2Fjd/EfycdewM9sSYvkuoGj48aaPuVrkzxAccCUChlANsVHOrnsvi58et1iZy0MME NVq5UNfSsTBkWK+pzGAsLcdI0snGqF/mzuW8HeW89X19hSZW0mR04lzbFCV3XEDvXqAc KBh7ZO9vJ4lmFMj8aOrpFW1g9vyXc+MtAZApKcum3dgtQz6eOiQCV8i3u4iT88oTaWH9 9dkuoD0TUfl6/sS20ROSPt9N8/R5wru+nNabtwtSjRS05xlO7ICNY5YghyMd74qjZamG RDJ3hx99EFaBXltxuwuAzniRiy2nzF8snjY7YpEo6ioN17JFvYQpzRBOg0LIyL0gJNQQ Pm7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=pP1WoEAAJ+vCb8OBFKknF0fFWhXHfTf1dyCM1yg832g=; b=ZawrRiYVBh9KM8F7vme6SxZNrOqSzabhD0YpqSqe9z0AI3ZDgtiknwBpMVyrB/YHqt BLNlBPbbpb0JX6yryv9wBn5zxj41WbH6rAp8q2w2JukTx9XqIwly22LvFuTkk1r1gA3G Aw3+kPeXto01OHMZnQXx6Sn8Fm4MHTGR5K4KDr+ishrUyiL0wDIMTzl//Wqg9AUvEki2 kRE1bYILjrI3aBLigsfir0tEd0EWcOxcFmH8fwtAHzRUIt724ljOJD2w27J6RVciJi8H oMBRu5BaOvZD5GnDYTx5Ae5AuSG6PT1HcY08P69tGf+7LSAep5l4LnJumCiShDwP9v4J gNLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="FJX0/9d+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g6si1083038ejx.444.2021.10.08.16.46.33; Fri, 08 Oct 2021 16:46:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="FJX0/9d+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243798AbhJHXrL (ORCPT + 99 others); Fri, 8 Oct 2021 19:47:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231964AbhJHXrK (ORCPT ); Fri, 8 Oct 2021 19:47:10 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56B7BC061570 for ; Fri, 8 Oct 2021 16:45:14 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id u18so45172847lfd.12 for ; Fri, 08 Oct 2021 16:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pP1WoEAAJ+vCb8OBFKknF0fFWhXHfTf1dyCM1yg832g=; b=FJX0/9d+9/kpnygHrvLnZLoEUcFi9QeR+n8y7ETuFGcSeUX/GfSwAWiZYJt+KrK+16 o7aNcNa5SFwi07Bj8egMGz6yvecVTkbfebnSBL89tQA+uct6+oGUcGWaZDkl0NKm8CYl jtOIwUAhQdluZknXm/0gWssbx948AUYIvrgh9S0rhFhVvixrH3dtGqpFtAc++Q96dlI2 xOhUTUGcvHUZ0bH1WCb14U5zszyNsgGrGSyXT9eUSr/a0ge/TJ5d0MbKyLrQsJidpmd/ nJtVdHZbnHrsTAIrBdRYf0eCt0Oxacv5SmhtJ5sswq9FweyGGnPPfRzGzVBUcSOf5898 jwCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pP1WoEAAJ+vCb8OBFKknF0fFWhXHfTf1dyCM1yg832g=; b=x6MHrDH83LzfJY83U+ybOuc1sFwctZLr1QmRC77SaFdzJV7IUuqVsNClrN8IYJ57M2 27cOYL3LqOlKpCx0L9hcENamggT4czjjdjkV65eE+QNgxTJLZXu146xlcy2q97GUVUgb XwjZS1kdr2lHyyIZi0D1Dh1GWUEvCVkZIrtO4pKfgx2LKo4I2r6XTj1VXDkhyz97M2ev ZDiV3uNaAvRuQbKOV24IYj+yFCMdPxqismhuFGr4OXhZiNPBcx+wHY3GjEOEAmAC0Xnx 9aVe8bhBwCkhEpNu4RWDKUaNBwPYJqSNz7Kn3dINFOH0nFQa/EBnp7knlVkY8+GYOKHy OZkA== X-Gm-Message-State: AOAM530yBIfVZ7cmjgQjuGPNHdCXNy7aG/mqViom4CK6UW5Qf0ZfPPLp gBIqb0Np40qxGCa7Cf/VYWqkwnhjrBJDbKqq+B8e/g== X-Received: by 2002:a19:711d:: with SMTP id m29mr12215247lfc.36.1633736712722; Fri, 08 Oct 2021 16:45:12 -0700 (PDT) MIME-Version: 1.0 References: <20211008080305.13401-1-yanghui.def@bytedance.com> In-Reply-To: <20211008080305.13401-1-yanghui.def@bytedance.com> From: John Stultz Date: Fri, 8 Oct 2021 16:45:01 -0700 Message-ID: Subject: Re: [PATCH] Clocksource: Avoid misjudgment of clocksource To: yanghui Cc: Thomas Gleixner , Stephen Boyd , lkml Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 8, 2021 at 1:03 AM yanghui 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 > --- > 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. thanks -john