From: Jiri Wiesner <jwiesner@suse.de>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org, John Stultz <jstultz@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Stephen Boyd <sboyd@kernel.org>, Feng Tang <feng.tang@intel.com>
Subject: Re: [PATCH] clocksource: Skip watchdog check for large watchdog intervals
Date: Thu, 4 Jan 2024 17:30:50 +0100 [thread overview]
Message-ID: <20240104163050.GC3303@incl> (raw)
In-Reply-To: <5b8fd9ba-1622-4ec7-b3cc-2db3a78122f1@paulmck-laptop>
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.
--
Jiri Wiesner
SUSE Labs
next prev parent reply other threads:[~2024-01-04 16:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 11:21 [PATCH] clocksource: Skip watchdog check for large watchdog intervals Jiri Wiesner
2024-01-03 22:08 ` Paul E. McKenney
2024-01-04 16:30 ` Jiri Wiesner [this message]
2024-01-04 19:19 ` Paul E. McKenney
2024-01-06 2:55 ` Feng Tang
2024-01-06 12:04 ` Paul E. McKenney
2024-01-04 0:46 ` kernel test robot
2024-01-04 0:57 ` kernel test robot
2024-01-04 5:55 ` Feng Tang
2024-01-04 16:48 ` Jiri Wiesner
2024-01-08 13:44 ` kernel test robot
2024-01-10 18:36 ` Jiri Wiesner
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=20240104163050.GC3303@incl \
--to=jwiesner@suse.de \
--cc=feng.tang@intel.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.