Received-SPF: pass (google.com: domain of linux-kernel+bounces-18464-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Sat, 6 Jan 2024 10:55:09 +0800
From: Feng Tang <feng.tang@intel.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
CC: Jiri Wiesner <jwiesner@suse.de>, <linux-kernel@vger.kernel.org>, "John
 Stultz" <jstultz@google.com>, Thomas Gleixner <tglx@linutronix.de>, "Stephen
 Boyd" <sboyd@kernel.org>, <rui.zhang@intel.com>
Subject: Re: [PATCH] clocksource: Skip watchdog check for large watchdog
 intervals
Message-ID: <ZZjBDaW9tqSEicNM@feng-clx>
References: <20240103112113.GA6108@incl>
 <5b8fd9ba-1622-4ec7-b3cc-2db3a78122f1@paulmck-laptop>
 <20240104163050.GC3303@incl>
 <dd62437f-b7a2-4844-89f6-94a88a08f227@paulmck-laptop>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <dd62437f-b7a2-4844-89f6-94a88a08f227@paulmck-laptop>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tCawsPb7nv8lpC2PFCWLO0JBs2tO+peLv8Ua6QClon2maaLEiDF6uyAoo+ta?=
 =?us-ascii?Q?TssQS4FVxjM1fRKsZyWDrl5Z6CIRvDAxCSDhYWM+tWFpsrZH3lP7pRuaQl5T?=
 =?us-ascii?Q?ct0sDECM579J6IV2vEq8YjMLD5V3P9s39sk/l7C6dDRfptl/uMn4n2gt5wDz?=
 =?us-ascii?Q?xhCc1xfJ+YJfLECWKJek8vtbw9xltem4eBjCf6QPKLL9LGLFcn8ZV6QuxU0R?=
 =?us-ascii?Q?Q4eoUV16uVLYXHKEGhdZfnUe+O/vGV0dzUWCazuELwecqG1ESozKUZZWCN0G?=
 =?us-ascii?Q?3xS4CzfMvltN8FUMJZcy2s1eseHSOdsoUpek5MBD2LYPkrSfXpd+WnFFLFgC?=
 =?us-ascii?Q?JnsLTBiXV810og91c0ZyMIYo6xma6v+Ff0tQ8PrgwBx0Hkp1rlOH3ENFbX1v?=
 =?us-ascii?Q?g5ZhDoH2jUqp0i390136UF4o3swypT1EmKx9Lw5nj3s8DWqpGtq5TOypzhxu?=
 =?us-ascii?Q?/Rf/jvFbvrpivKKwU+Zx/yjCMXbKMnk7RphFmqtnbrMwVFb0S9gTAosPjHvi?=
 =?us-ascii?Q?GefRhsVzakPUQXbnYeYuuySF69HsZLRPgg9CRkUZOLa48wXC0jGUf8rcqGoo?=
 =?us-ascii?Q?7uwYaJP6nqPwV6Q5K45qzzHkWKX/q5pN3OzfGOhQ9kcKDQbrxXZz8VigHwGc?=
 =?us-ascii?Q?45N7AK0g3fiYw6U136KOzVqbyoa5eVtztguWcSqfGHr+Vd7t+5WvMZeh5PKM?=
 =?us-ascii?Q?zo6bmsvvIHXv9cLFKf2XZkRRDdrmIA0+450ktwogc7Poe5CjQBhf3nZJBAbM?=
 =?us-ascii?Q?1pMrolPeHT79UZrlWpKAub95Tqx8v6xuHwGE/xA+aLvFML0Xl65J37CeP7HZ?=
 =?us-ascii?Q?r2O4lif4peYcksMScI0xtndwpVULPtf+ibHFRnTAhxvT6MdmsOrikMJCW0I+?=
 =?us-ascii?Q?mw0uLYXDezCkwzGH3j7zjaMfHBNz9Vgm4kg+Ca4ix+VtE48yil6yzKbM8+ic?=
 =?us-ascii?Q?qaNCuLFJ2t9X7pM2VsY3WQG7ViwKnJL3azSVrMfkbywvdjsju5KFdFhy4cTT?=
 =?us-ascii?Q?Qmf+z2m6q5eey+wxRxmU9m5eKlyWqLNpWWCgB30qvkV75aWwSooMwVtK5szq?=
 =?us-ascii?Q?SWXsrMJNBiw9zKEk8DnOMH2/nsDABdJHVtQu/7T8s/Zh36rSGvrC3cyFy85s?=
 =?us-ascii?Q?vehm5PWts50SaaCkAtWJve5KlzKXAqTE44iwyTDIiM7KI+ogxTBEYIHDaKj7?=
 =?us-ascii?Q?GHpUw7Fp8+b+MAtpX4MjU706lklSogPQh8TFvps1r3iTBJY4xBfLC+sCFut5?=
 =?us-ascii?Q?ZzuX/szAWONr6VAHAf63dEaNd27JrCpEb5cCaVqS4LH4E5sM8X1AKCVG/QpG?=
 =?us-ascii?Q?53ge507l/7g6EdjKJeNVMV/4Gt8xXvOK9EfdiuADgwvLKJbhIl9r1EmwYcq9?=
 =?us-ascii?Q?mB/lGqhSoOwo6IgpueD0Zz1HD7s4OxrxwG6PxPLUQza6RVDJs6ejmFGC0gaH?=
 =?us-ascii?Q?7gG8UBPcUPXW/nShfMZPDAFXxoA3XwKwxKZV3Vf6DYfT1SDlcQcBEeRKeezP?=
 =?us-ascii?Q?oLQ3o4Sv6nqb4CqV/POcazL05uvNPMRyv2VD5nFjKkL8+gG1WF3q4m0aSuRV?=
 =?us-ascii?Q?+mmSxpFTaPoBZ4GB5HJZrpzCkT54o3Oat5NBQ6+H?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ef25c8a-8f9d-432d-e44b-08dc0e64201f
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2024 03:03:57.9598
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RbqVdwF4BkUH4hlyfit68O/54GqB7KgQGydQKBlvWScWEutqW6Ffv0kmV+KjQ2r4gWl+DtA2b381DvmBG6X4Og==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6236
X-OriginatorOrg: intel.com

On Thu, Jan 04, 2024 at 11:19:56AM -0800, Paul E. McKenney wrote:
> On Thu, Jan 04, 2024 at 05:30:50PM +0100, Jiri Wiesner wrote:
> > On Wed, Jan 03, 2024 at 02:08:08PM -0800, Paul E. McKenney wrote:
> > > I believe that there were concerns about a similar approach in the case
> > > where the jiffies counter is the clocksource
> > 
> > I ran a few simple tests on a 2 NUMA node Intel machine and found nothing 
> > so far. I tried booting with clocksource=jiffies and I changed the 
> > "nr_online_nodes <= 4" check in tsc_clocksource_as_watchdog() to enable 
> > the watchdog on my machine. I have a debugging module that monitors 
> > clocksource and watchdog reads in clocksource_watchdog() with kprobes. I 
> > see the cs/wd reads executed roughly every 0.5 second, as expected. When 
> > the machine is idle the average watchdog interval is 501.61 milliseconds 
> > (+-15.57 ms, with a minimum of 477.07 ms and a maximum of 517.93 ms). The 
> > result is similar when the CPUs of the machine are fully saturated with 
> > netperf processes. I also tried booting with clocksource=jiffies and 
> > tsc=watchdog. The watchdog interval was similar to the previous test.
> > 
> > AFAIK, the jiffies clocksource does get checked by the watchdog itself. 
> > And with that, I have run out of ideas.
> 
> If I recall correctly (ha!), the concern was that with the jiffies as
> clocksource, we would be using jiffies (via timers) to check jiffies
> (the clocksource), and that this could cause issues if the jiffies got
> behind, then suddenly updated while the clocksource watchdog was running.

Yes, we also met problem when 'jiffies' was used as clocksource/watchdog,
but don't know if it's the same problem you mentioned. Our problem
('jiffies' as watchdog marks clocksource TSC as unstable) only happens
in early boot phase with serial earlyprintk enabled, that the updating
of 'jiffies' relies on HW timer's periodic interrupt, but early printk
will disable interrupt during printing and cause some timer interrupts
lost, and hence big lagging in 'jiffies'. Rui once proposed a patch to
prevent 'jiffies' from being a watchdog due to it unreliability [1].

And I think skipping the watchdog check one time when detecting some
abnormal condition won't hurt the overall check much.

[1]. https://lore.kernel.org/lkml/bd5b97f89ab2887543fc262348d1c7cafcaae536.camel@intel.com/

Thanks,
Feng

> Thoughts?
> 
> 							Thanx, Paul