From: "Paul E. McKenney" <paulmck@kernel.org>
To: kernel test robot <lkp@intel.com>
Cc: tglx@linutronix.de, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org, john.stultz@linaro.org,
sboyd@kernel.org, corbet@lwn.net, Mark.Rutland@arm.com,
maz@kernel.org, kernel-team@fb.com, neeraju@codeaurora.org,
ak@linux.intel.com
Subject: Re: [PATCH v11 clocksource 6/6] clocksource: Reduce clocksource-skew threshold for TSC
Date: Thu, 29 Apr 2021 07:04:40 -0700 [thread overview]
Message-ID: <20210429140440.GT975577@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <202104291438.PuHsxRkl-lkp@intel.com>
On Thu, Apr 29, 2021 at 03:02:36PM +0800, kernel test robot wrote:
> Hi "Paul,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on tip/timers/core]
> [also build test ERROR on tip/x86/core linux/master linus/master v5.12]
> [cannot apply to next-20210428]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Paul-E-McKenney/Do-not-mark-clocks-unstable-due-to-delays-for-v5-13/20210429-093259
> base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 2d036dfa5f10df9782f5278fc591d79d283c1fad
> config: riscv-randconfig-p002-20210428 (attached as .config)
> compiler: riscv64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://github.com/0day-ci/linux/commit/26be1e45593936a0c04aa1d268522f8c1cb646de
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Paul-E-McKenney/Do-not-mark-clocks-unstable-due-to-delays-for-v5-13/20210429-093259
> git checkout 26be1e45593936a0c04aa1d268522f8c1cb646de
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=riscv
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> kernel/time/clocksource.c: In function '__clocksource_update_freq_scale':
> >> kernel/time/clocksource.c:1094:36: error: 'WATCHDOG_MAX_SKEW' undeclared (first use in this function)
> 1094 | if (cs->uncertainty_margin < 2 * WATCHDOG_MAX_SKEW)
> | ^~~~~~~~~~~~~~~~~
> kernel/time/clocksource.c:1094:36: note: each undeclared identifier is reported only once for each function it appears in
> >> kernel/time/clocksource.c:1097:28: error: 'WATCHDOG_THRESHOLD' undeclared (first use in this function)
> 1097 | cs->uncertainty_margin = WATCHDOG_THRESHOLD;
> | ^~~~~~~~~~~~~~~~~~
Does the patch below help?
Longer term, these definitions will likely need to instead go into
a header file, but to move testing along in the here and now...
Thanx, Paul
------------------------------------------------------------------------
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index c228f3727191..328a65ddb959 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -96,6 +96,20 @@ static char override_name[CS_NAME_LEN];
static int finished_booting;
static u64 suspend_start;
+/*
+ * Threshold: 0.0312s, when doubled: 0.0625s.
+ * Also a default for cs->uncertainty_margin when registering clocks.
+ */
+#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 5)
+
+/*
+ * Maximum permissible delay between two readouts of the watchdog
+ * clocksource surrounding a read of the clocksource being validated.
+ * This delay could be due to SMIs, NMIs, or to VCPU preemptions. Used as
+ * a lower bound for cs->uncertainty_margin values when registering clocks.
+ */
+#define WATCHDOG_MAX_SKEW (50 * NSEC_PER_USEC)
+
#ifdef CONFIG_CLOCKSOURCE_WATCHDOG
static void clocksource_watchdog_work(struct work_struct *work);
static void clocksource_select(void);
@@ -122,17 +136,9 @@ static int clocksource_watchdog_kthread(void *data);
static void __clocksource_change_rating(struct clocksource *cs, int rating);
/*
- * Interval: 0.5sec Threshold: 0.0312s, when doubled: 0.0625s
+ * Interval: 0.5sec.
*/
#define WATCHDOG_INTERVAL (HZ >> 1)
-#define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 5)
-
-/*
- * Maximum permissible delay between two readouts of the watchdog
- * clocksource surrounding a read of the clocksource being validated.
- * This delay could be due to SMIs, NMIs, or to VCPU preemptions.
- */
-#define WATCHDOG_MAX_SKEW (50 * NSEC_PER_USEC)
static void clocksource_watchdog_work(struct work_struct *work)
{
next prev parent reply other threads:[~2021-04-29 14:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 1:29 [PATCH V11 clocksource 0/6] Do not mark clocks unstable due to delays for v5.13 Paul E. McKenney
2021-04-29 1:30 ` [PATCH v11 clocksource 1/6] clocksource: Provide module parameters to inject delays in watchdog Paul E. McKenney
2021-04-29 1:30 ` [PATCH v11 clocksource 2/6] clocksource: Retry clock read if long delays detected Paul E. McKenney
2021-04-29 1:30 ` [PATCH v11 clocksource 3/6] clocksource: Check per-CPU clock synchronization when marked unstable Paul E. McKenney
2021-04-29 1:30 ` [PATCH v11 clocksource 4/6] clocksource: Provide a module parameter to fuzz per-CPU clock checking Paul E. McKenney
2021-04-29 1:30 ` [PATCH v11 clocksource 5/6] clocksource: Limit number of CPUs checked for clock synchronization Paul E. McKenney
2021-04-29 1:30 ` [PATCH v11 clocksource 6/6] clocksource: Reduce clocksource-skew threshold for TSC Paul E. McKenney
2021-04-29 7:02 ` kernel test robot
2021-04-29 14:04 ` Paul E. McKenney [this message]
2021-04-29 11:13 ` [PATCH V11 clocksource 0/6] Do not mark clocks unstable due to delays for v5.13 Luming Yu
2021-04-30 5:10 ` Paul E. McKenney
2021-04-30 6:52 ` Luming Yu
2021-05-01 4:28 ` Paul E. McKenney
2021-06-02 5:10 ` Luming Yu
2021-06-02 17:46 ` Paul E. McKenney
2021-06-02 18:24 ` Paul E. McKenney
2021-06-03 4:25 ` Luming Yu
2021-06-03 14:40 ` Paul E. McKenney
2021-06-04 4:23 ` Luming Yu
2021-06-04 20:26 ` 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=20210429140440.GT975577@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=Mark.Rutland@arm.com \
--cc=ak@linux.intel.com \
--cc=corbet@lwn.net \
--cc=john.stultz@linaro.org \
--cc=kbuild-all@lists.01.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=maz@kernel.org \
--cc=neeraju@codeaurora.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;
as well as URLs for NNTP newsgroup(s).