[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tunwvmmu.ffs@nanos.tec.linutronix.de>
Date: Fri, 23 Apr 2021 21:14:49 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: paulmck@...nel.org, Feng Tang <feng.tang@...el.com>
Cc: Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
John Stultz <john.stultz@...aro.org>,
Stephen Boyd <sboyd@...nel.org>,
Jonathan Corbet <corbet@....net>,
Mark Rutland <Mark.Rutland@....com>,
Marc Zyngier <maz@...nel.org>, Andi Kleen <ak@...ux.intel.com>,
Chris Mason <clm@...com>, LKML <linux-kernel@...r.kernel.org>,
lkp@...ts.01.org, lkp@...el.com
Subject: Re: [LKP] Re: [clocksource] 6c52b5f3cf: stress-ng.opcode.ops_per_sec -14.4% regression
On Thu, Apr 22 2021 at 07:24, Paul E. McKenney wrote:
> On Thu, Apr 22, 2021 at 03:41:26PM +0800, Feng Tang wrote:
> So what are our options?
>
> 1. Clear CLOCK_SOURCE_MUST_VERIFY from tsc-early.
>
> 2. #1, but add tsc-early into the watchdog list and set
> CLOCK_SOURCE_MUST_VERIFY once it is better calibrated.
>
> 3. Add a field to struct clocksource that, if non-zero, gives
> the maximum drift in nanoseconds per half second (AKA
> WATCHDOG_INTERVAL). If zero, the WATCHDOG_MAX_SKEW value
> is used. Set this to (say) 150,000ns for tsc-early.
>
> 4. As noted earlier, increase WATCHDOG_MAX_SKEW to 150 microseconds,
> which again is not a good approach given the real-world needs
> of real-world applications.
>
> 5. Your ideas here.
#3 or add a flag to the clocksource which says 'frequency is guesswork' and
increase the threshold based on that.
If that flag is still set max_drift is != 0 after 20 seconds yell.
Thanks,
tglx
Powered by blists - more mailing lists