[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230111213210.GA4028633@paulmck-ThinkPad-P17-Gen-1>
Date: Wed, 11 Jan 2023 13:32:10 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, john.stultz@...aro.org,
sboyd@...nel.org, corbet@....net, Mark.Rutland@....com,
maz@...nel.org, kernel-team@...a.com, neeraju@...eaurora.org,
ak@...ux.intel.com, feng.tang@...el.com, zhengjun.xing@...el.com,
Waiman Long <longman@...hat.com>,
John Stultz <jstultz@...gle.com>
Subject: Re: [PATCH clocksource 5/6] clocksource: Suspend the watchdog
temporarily when high read latency detected
On Wed, Jan 11, 2023 at 10:19:50PM +0100, Thomas Gleixner wrote:
> On Wed, Jan 11 2023 at 09:50, Paul E. McKenney wrote:
> > On Wed, Jan 11, 2023 at 12:26:58PM +0100, Thomas Gleixner wrote:
> > Yes, if a system was 100% busy forever, this patch would suppress these
> > checks. But 100% busy forever is not the common case, due to thermal
> > throttling and to security updates if nothing else.
> >
> > With all that said, is there a better way to get the desired effects of
> > this patch?
>
> Sane hardware?
I must let Feng talk to his systems, but most of the systems I saw were
production systems. A few were engineering samples, from which some
insanity might be expected behavior.
Clearly, something about the hardware or firmware was insane in order
to get this result, but that is what diagnostics are for, even on
engineering samples.
Thanx, Paul
Powered by blists - more mailing lists