All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitri Sivanich <sivanich@hpe.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Jiri Wiesner" <jwiesner@suse.de>,
	"Steve Wahl" <steve.wahl@hpe.com>,
	"Justin Ernst" <justin.ernst@hpe.com>,
	"Kyle Meyer" <kyle.meyer@hpe.com>,
	"Russ Anderson" <russ.anderson@hpe.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Marco Elver" <elver@google.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	"Nikunj A Dadhania" <nikunj@amd.com>,
	"Xin Li (Intel)" <xin@zytor.com>,
	"Dimitri Sivanich" <dimitri.sivanich@hpe.com>
Subject: Re: [PATCH v4 0/2] x86/tsc: Exempt recent UV systems from clocksource watchdog checks to avoid false positives.
Date: Thu, 21 May 2026 21:08:34 -0500	[thread overview]
Message-ID: <ag-6okJPQs7MMcis@hpe.com> (raw)
In-Reply-To: <87lddcv9vd.ffs@tglx>

On Thu, May 21, 2026 at 09:30:14PM +0200, Thomas Gleixner wrote:
> On Thu, May 21 2026 at 08:17, Dimitri Sivanich wrote:
> > HPE UV hardware and firmware is designed to ensure a reliable and
> > synchronized TSC mechanism.  Comparing the TSC against secondary
> > clocksources can result in false positives due to variable access
> > latency caused by system traffic.  The best course of action against
> > these false positives has been found to simply disable watchdog
> > checking of the TSC.
> >
> > Commits [1] and [2] were introduced to avoid an issue where the TSC
> > is falsely declared unstable by exempting qualified platforms of up
> > to 4-sockets from TSC clocksource watchdog checking.  Extend that
> > exemption to include recent and future UV platforms.
> 
> Jiri asked you in the V3 submission:
> 
>  "A new implementation of the clocksource watchdog has been merged into
>   the upstream kernel. One of the changes made by the new clocksource
>   watchdog implementation is that reference clocksource reads are made
>   on the boot CPU only. Perhaps, the sgi_rtc clocksource would work well
>   with this implementation. So, testing is needed in order to find out
>   if this patch are any future in the upstream Linux. Dimitri, would you
>   be able to run tests on UV systems to check if the new clocksource
>   watchdog implementation works and the hardware limitations of sgi_rtc
>   do not get in the way?"
> 
> This question is still not answered by you and it has been confirmed
> that the new watchdog works flawlessly on a 1920 threads 16 socket
> system under massive load and system traffic.

I tested a 7.1-rc4 kernel on a 2048 thread 16 socket system and, while
under test, the TSC did get marked as unstable after a series of "sgi_rtc
read timed out" warnings.

> 
> So you do not even have the courtesy to test, you just go and make the
> same claims you made before based on the original watchdog
> implementation.
> 
> Feel free to ignore people, but then don't be surprised when people
> ignore you as well.
> 
> Thanks,
> 
>         tglx

      reply	other threads:[~2026-05-22  2:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-21 13:17 [PATCH v4 0/2] x86/tsc: Exempt recent UV systems from clocksource watchdog checks to avoid false positives Dimitri Sivanich
2026-05-21 13:20 ` [PATCH v4 1/2] x86/platform/uv: Expose the uv_hub_type() interface Dimitri Sivanich
2026-05-21 13:23 ` [PATCH v4 2/2] x86/tsc: Disable clocksource watchdog checking on recent and future UV platforms Dimitri Sivanich
2026-05-21 19:30 ` [PATCH v4 0/2] x86/tsc: Exempt recent UV systems from clocksource watchdog checks to avoid false positives Thomas Gleixner
2026-05-22  2:08   ` Dimitri Sivanich [this message]

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=ag-6okJPQs7MMcis@hpe.com \
    --to=sivanich@hpe.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dimitri.sivanich@hpe.com \
    --cc=elver@google.com \
    --cc=gpiccoli@igalia.com \
    --cc=hpa@zytor.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=justin.ernst@hpe.com \
    --cc=jwiesner@suse.de \
    --cc=kyle.meyer@hpe.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nikunj@amd.com \
    --cc=peterz@infradead.org \
    --cc=russ.anderson@hpe.com \
    --cc=steve.wahl@hpe.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /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.