[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877dkmmq4q.ffs@nanos.tec.linutronix.de>
Date: Wed, 28 Apr 2021 16:37:41 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Luming Yu <luming.yu@...il.com>, paulmck@...nel.org
Cc: Andi Kleen <ak@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>, john.stultz@...aro.org,
sboyd@...nel.org, corbet@....net, Mark.Rutland@....com,
maz@...nel.org, kernel-team@...com, neeraju@...eaurora.org,
feng.tang@...el.com, zhengjun.xing@...el.com,
Chris Mason <clm@...com>
Subject: Re: [PATCH v10 clocksource 1/7] clocksource: Provide module parameters to inject delays in watchdog
On Wed, Apr 28 2021 at 22:24, Luming Yu wrote:
> On Wed, Apr 28, 2021 at 9:57 PM Paul E. McKenney <paulmck@...nel.org> wrote:
>> Therefore, the code marks the clock unstable if it has four bad reads
>> in a row, as it should.
>
> The hard problem to solve is tsc is still in good shape and it can be verified
> with a quick cross check with other thread/core's tsc counts in the
> injected situation or in real life case
> to prove if it is truly a tsc problem or reference clock's problem of
> the watchdog.
>
> Ideally, we could factor out hard-to-debug unstable tsc problems from
> clock source watchdog problems
> and get less and less tsc sightings caused by clock source watchdog.
The only way to fix this is at the hardware level. Everything else is
wishful thinking.
Thanks,
tglx
Powered by blists - more mailing lists