[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211201012655.GA20240@shbuild999.sh.intel.com>
Date: Wed, 1 Dec 2021 09:26:55 +0800
From: Feng Tang <feng.tang@...el.com>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...el.com>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, rui.zhang@...el.com,
andi.kleen@...el.com, len.brown@...el.com, tim.c.chen@...el.com
Subject: Re: [PATCH v3 2/2] x86/tsc: skip tsc watchdog checking for qualified
platforms
On Tue, Nov 30, 2021 at 03:37:26PM -0800, Paul E. McKenney wrote:
> 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? ;-)
For HPET, it's a long story :) Back in 2012 or so, the HPET on Baytrail
platform has a new feature that it will stop counting in PC10 (a cpuidle
state), which prevent it to be a clocksource, and we have to disable
HPET explicitly for that platform. Since then, some new platforms also
have the same feature, and their HPET got disabled too.
Thanks,
Feng
Powered by blists - more mailing lists