linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Feng Tang <feng.tang@intel.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	Xing Zhengjun <zhengjun.xing@linux.intel.com>,
	John Stultz <john.stultz@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>, Andi Kleen <ak@linux.intel.com>,
	Chris Mason <clm@fb.com>, LKML <linux-kernel@vger.kernel.org>,
	"lkp\@lists.01.org" <lkp@lists.01.org>, lkp <lkp@intel.com>
Subject: Re: [LKP] Re: [clocksource] 6c52b5f3cf: stress-ng.opcode.ops_per_sec -14.4% regression
Date: Mon, 26 Apr 2021 16:33:31 +0200	[thread overview]
Message-ID: <87fszdt8sk.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20210426140512.GA23119@shbuild999.sh.intel.com>

On Mon, Apr 26 2021 at 22:05, Feng Tang wrote:
> On Mon, Apr 26, 2021 at 08:39:25PM +0800, Thomas Gleixner wrote:
>> On Sat, Apr 24 2021 at 20:29, Feng Tang wrote:
>> > On Fri, Apr 23, 2021 at 07:02:54AM -0700, Paul E. McKenney wrote:
>> > And I'm eager to know if there is any real case of an unreliable tsc
>> > on the 'large numbers' of x86 system which complies with our cpu feature
>> > check. And if there is, my 2/2 definitely should be dropped.   
>> 
>> Nothing prevents BIOS tinkerers from trying to be 'smart'. My most
>> recent encounter (3 month ago) was on a laptop where TSC drifted off on
>> CPU0 very slowly, but was caught due to the TSC_ADJUST check in idle.
>
> Thanks for sharing the info! So this laptop can still work with the
> tsc_adjust check and restore, without triggering the 'unstable' alarm.
>
> Why are those BIOSes playing the trick? Maybe some other OS has hard limit
> for SMI's maxim handling time, so they try to hide the time?

Years ago someone admitted that it was the attempt to hide the
(substantial) time wasted in SMIs from being detectable via tracing, but
obviously that backfired because TSC got out of sync.

Since then this has mostly vanished but for some reasons it's coming
back every now and then. Rarely, but it happens still.

>> I'm still thinking about a solution to avoid that extra timer and the
>> watchdog for these systems, but haven't found anything which I don't
>> hate with a passion yet.
>
> I see. So should I hold my two patches (tsc_adjust timer and tsc watchdog
> check lifting) for a while?

I have them on my list anyway, but yes we want to avoid the timer
because that's what the HPC / NOHZ full people are going to complain
about anyway.

Thanks,

        tglx

  reply	other threads:[~2021-04-26 14:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  6:49 [clocksource] 6c52b5f3cf: stress-ng.opcode.ops_per_sec -14.4% regression kernel test robot
2021-04-20 13:43 ` Paul E. McKenney
2021-04-20 14:05   ` Paul E. McKenney
2021-04-21  6:07     ` [LKP] " Xing, Zhengjun
2021-04-21 13:42       ` Paul E. McKenney
2021-04-22  6:58         ` Xing Zhengjun
2021-04-22  7:41           ` Feng Tang
2021-04-22 14:24             ` Paul E. McKenney
2021-04-22 16:57               ` Paul E. McKenney
2021-04-23  6:11                 ` Feng Tang
2021-04-23 14:02                   ` Paul E. McKenney
2021-04-24 12:29                     ` Feng Tang
2021-04-24 17:53                       ` Paul E. McKenney
2021-04-25  2:14                         ` Feng Tang
2021-04-25  3:14                           ` Feng Tang
2021-04-25 19:15                             ` Paul E. McKenney
2021-04-25 19:14                           ` Paul E. McKenney
2021-04-26 12:39                       ` Thomas Gleixner
2021-04-26 14:05                         ` Feng Tang
2021-04-26 14:33                           ` Thomas Gleixner [this message]
2021-04-26 15:12                             ` Feng Tang
2021-04-23  2:15               ` Xing Zhengjun
2021-04-23  4:12                 ` Paul E. McKenney
2021-04-23 19:14               ` Thomas Gleixner
2021-04-23 21:14                 ` Paul E. McKenney
2021-04-23 23:39                   ` Paul E. McKenney
2021-04-23 19:09             ` Thomas Gleixner

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=87fszdt8sk.ffs@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=Mark.Rutland@arm.com \
    --cc=ak@linux.intel.com \
    --cc=clm@fb.com \
    --cc=corbet@lwn.net \
    --cc=feng.tang@intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=maz@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=zhengjun.xing@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).