From: "Paul E. McKenney" <paulmck@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Feng Tang <feng.tang@intel.com>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@intel.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
rui.zhang@intel.com, andi.kleen@intel.com, len.brown@intel.com,
tim.c.chen@intel.com
Subject: Re: [PATCH v3 2/2] x86/tsc: skip tsc watchdog checking for qualified platforms
Date: Tue, 30 Nov 2021 15:37:26 -0800 [thread overview]
Message-ID: <20211130233726.GD641268@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <87tuft9qpc.ffs@tglx>
On Wed, Dec 01, 2021 at 12:19:43AM +0100, Thomas Gleixner wrote:
> On Tue, Nov 30 2021 at 14:48, Paul E. McKenney wrote:
> > On Tue, Nov 30, 2021 at 10:55:45PM +0100, Thomas Gleixner wrote:
> >> > OK, HPET or nothing, then.
> >>
> >> Older machines also have pm_timer. But those beasts seem to have lost
> >> that too.
> >
> > I suppose that one way of avoiding clock-skew messages is to have only
> > one clock.
>
> Indeed. It's a complete mystery why it takes ages to implement reliable
> clocks in hardware.
That one is easy. It is because the previous clocksource watchdog was
too lenient. ;-)
(Sorry, couldn't resist...)
> >> >> We really need to remove the watchdog requirement for modern hardware.
> >> >> Let me stare at those patches and get them merged.
> >> >
> >> > You are more trusting of modern hardware than I am, but for all I know,
> >> > maybe rightfully so. ;-)
> >>
> >> Well, I rather put a bet on the hardware, which has become reasonable
> >> over the last decade, than on trying to solve a circular dependency
> >> problem with tons of heuristics which won't ever work correctly.
> >
> > Use of HPET to check the interval length would not be circular, right?
>
> As long as the HPET works reliably :)
Is it also a complete mystery why clocksources previously deemed
reliable no longer work reliably? ;-)
> >> TSC_ADJUST is a reasonable safety net and since its invention the amount
> >> of BIOS wreckage has been massively reduced. Seems the nastigram in
> >> dmesg when detecting a change in TSC_ADJUST had an effect or maybe
> >> Microsoft enforces a tinkerfree TSC by now and we get the benefit. :)
> >>
> >> I still wish to have a knob to lock down TSC to read only, but that's
> >> probably for christmas 2030 or later. :)
> >
> > Indeed. How would BIOS writers hide their SMI handlers? :-/
>
> TSC_ADJUST already ruined that party.
Give the BIOS writers time, they will figure something else out. :-(
Thanx, Paul
next prev parent reply other threads:[~2021-11-30 23:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 2:37 [PATCH v3 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked Feng Tang
2021-11-17 2:37 ` [PATCH v3 2/2] x86/tsc: skip tsc watchdog checking for qualified platforms Feng Tang
2021-11-30 6:46 ` Feng Tang
2021-11-30 14:40 ` Paul E. McKenney
2021-11-30 15:02 ` Feng Tang
2021-11-30 16:28 ` Paul E. McKenney
2021-11-30 20:39 ` Thomas Gleixner
2021-11-30 20:47 ` Paul E. McKenney
2021-11-30 21:55 ` Thomas Gleixner
2021-11-30 22:48 ` Paul E. McKenney
2021-11-30 23:19 ` Thomas Gleixner
2021-11-30 23:37 ` Paul E. McKenney [this message]
2021-12-01 1:26 ` Feng Tang
2021-12-01 17:52 ` Paul E. McKenney
2021-12-07 1:41 ` Feng Tang
2021-12-01 4:45 ` Luming Yu
2021-12-01 5:19 ` Feng Tang
2021-12-01 10:41 ` Thomas Gleixner
2021-12-01 23:47 ` [tip: x86/urgent] x86/tsc: Disable clocksource watchdog for TSC on qualified platorms tip-bot2 for Feng Tang
2021-12-02 4:47 ` [PATCH v3 2/2] x86/tsc: skip tsc watchdog checking for qualified platforms Luming Yu
2021-12-01 23:47 ` [tip: x86/urgent] x86/tsc: Add a timer to make sure TSC_adjust is always checked tip-bot2 for Feng Tang
2022-03-14 17:52 ` [PATCH v3 1/2] x86/tsc: add a timer to make sure tsc_adjust " Nicolas Saenz Julienne
2022-03-15 1:33 ` Feng Tang
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=20211130233726.GD641268@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=andi.kleen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=feng.tang@intel.com \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@intel.com \
--cc=x86@kernel.org \
/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.