From: Feng Tang <feng.tang@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
linux-kernel@vger.kernel.org, Qais Yousef <qais.yousef@arm.com>,
andi.kleen@intel.com
Subject: Re: [PATCH] clocksource: don't run watchdog forever
Date: Thu, 4 Mar 2021 15:43:16 +0800 [thread overview]
Message-ID: <20210304074316.GA43191@shbuild999.sh.intel.com> (raw)
In-Reply-To: <875z286xtk.fsf@nanos.tec.linutronix.de>
Hi Thomas,
On Wed, Mar 03, 2021 at 04:50:31PM +0100, Thomas Gleixner wrote:
> On Tue, Mar 02 2021 at 20:06, Feng Tang wrote:
> > On Tue, Mar 02, 2021 at 10:16:37AM +0100, Peter Zijlstra wrote:
> >> On Tue, Mar 02, 2021 at 10:54:24AM +0800, Feng Tang wrote:
> >> > clocksource watchdog runs every 500ms, which creates some OS noise.
> >> > As the clocksource wreckage (especially for those that has per-cpu
> >> > reading hook) usually happens shortly after CPU is brought up or
> >> > after system resumes from sleep state, so add a time limit for
> >> > clocksource watchdog to only run for a period of time, and make
> >> > sure it run at least twice for each CPU.
> >> >
> >> > Regarding performance data, there is no improvement data with the
> >> > micro-benchmarks we have like hackbench/netperf/fio/will-it-scale
> >> > etc. But it obviously reduces periodic timer interrupts, and may
> >> > help in following cases:
> >> > * When some CPUs are isolated to only run scientific or high
> >> > performance computing tasks on a NOHZ_FULL kernel, where there
> >> > is almost no interrupts, this could make it more quiet
> >> > * On a cluster which runs a lot of systems in parallel with
> >> > barriers there are always enough systems which run the watchdog
> >> > and make everyone else wait
> >> >
> >> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> >>
> >> Urgh.. so this hopes and prays that the TSC wrackage happens in the
> >> first 10 minutes after boot.
>
> which is wishful thinking....
>
> > Yes, the 10 minutes part is only based on our past experience and we
> > can make it longer. But if there was real case that the wrackage happened
> > long after CPU is brought up like days, then this patch won't help
> > much.
>
> It really depends on the BIOS wreckage. On one of my machine it takes up
> to a day depending on the workload.
Thanks for sharing the info.
> Anything pre TSC_ADJUST wants the watchdog on. With TSC ADJUST available
> we can probably avoid it.
>
> There is a caveat though. If the machine never goes idle then TSC adjust
> is not able to detect a potential wreckage. OTOH, most of the broken
> BIOSes tweak TSC only by a few cycles and that is usually detectable
> during boot. So we might be clever about it and schedule a check every
> hour when during the first 10 minutes a modification of TSC adjust is
> seen on any CPU.
I don't have much experience with tsc_adjust, and try to understand it:
The 'modification of TSC' here has 2 cases: ?
* First read of 'TSC_ADJUST' MSR of a just boot CPU returns non-zero value
* Following read of 'TSC_ADJUST' doesn't equal to the 'tsc_adjust' value
saved in per-cpu data.
Also, does the patch ("x86/tsc: mark tsc reliable for qualified platforms")
need to wait till this caveat case is solved?
Thanks,
Feng
>
> Where is this TSC_DISABLE_WRITE bit again?
>
> Thanks,
>
> tglx
>
next prev parent reply other threads:[~2021-03-04 7:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 2:54 [PATCH] clocksource: don't run watchdog forever Feng Tang
2021-03-02 9:16 ` Peter Zijlstra
2021-03-02 12:06 ` Feng Tang
2021-03-03 15:50 ` Thomas Gleixner
2021-03-04 7:43 ` Feng Tang [this message]
2021-03-04 14:15 ` Thomas Gleixner
2021-03-05 2:30 ` Feng Tang
2021-03-25 8:34 ` Feng Tang
2021-03-25 11:40 ` 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=20210304074316.GA43191@shbuild999.sh.intel.com \
--to=feng.tang@intel.com \
--cc=andi.kleen@intel.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.