All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.