[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd62437f-b7a2-4844-89f6-94a88a08f227@paulmck-laptop>
Date: Thu, 4 Jan 2024 11:19:56 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Jiri Wiesner <jwiesner@...e.de>
Cc: linux-kernel@...r.kernel.org, John Stultz <jstultz@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>, Feng Tang <feng.tang@...el.com>
Subject: Re: [PATCH] clocksource: Skip watchdog check for large watchdog
intervals
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.
Thoughts?
Thanx, Paul
Powered by blists - more mailing lists