From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <waiman.long@hpe.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Jiang Liu <jiang.liu@linux.intel.com>,
Borislav Petkov <bp@suse.de>, Andy Lutomirski <luto@kernel.org>,
Scott J Norton <scott.norton@hpe.com>,
Douglas Hatch <doug.hatch@hpe.com>,
Randy Wright <rwright@hpe.com>
Subject: Re: [PATCH v4] x86/hpet: Reduce HPET counter read contention
Date: Thu, 14 Apr 2016 02:25:03 +0200 [thread overview]
Message-ID: <20160414002503.GQ2906@worktop> (raw)
In-Reply-To: <570E67B1.3000708@hpe.com>
On Wed, Apr 13, 2016 at 11:37:21AM -0400, Waiman Long wrote:
> The TSC clocksource, on the other hand, is per cpu. So there won't be much
> contention in accessing it. Normally TSC will be used the default clock
> source. However, if there is too much variation in the actual clock speeds
> of the individual CPUs,
Does the system actually have a clock rate skew? Not an offset?
> it will cause the TSC calibration to fail and revert
> to use hpet as the clock source. During bootup, hpet will usually be
> selected as the default clock source first. After a short time, the TSC will
> take over as the default clock source. Problem can happen during that short
> period of transition time too. In fact, we have 16-socket Broadwell-EX
> systems that has this soft lockup problem once in a few reboot cycles which
> prompted me to find a solution to fix it.
This 16 socket system is a completely broken trainwreck. Trying to use
HPET with _that_ many CPUs is absolutely insane.
Please tell your hardware engineers to fix the TSC clock domain.
next prev parent reply other threads:[~2016-04-14 0:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 18:46 [PATCH v4] x86/hpet: Reduce HPET counter read contention Waiman Long
2016-04-13 6:18 ` Ingo Molnar
2016-04-13 15:37 ` Waiman Long
2016-04-14 0:25 ` Peter Zijlstra [this message]
2016-04-14 2:10 ` Waiman Long
2016-05-12 23:20 ` Waiman Long
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=20160414002503.GQ2906@worktop \
--to=peterz@infradead.org \
--cc=bp@suse.de \
--cc=doug.hatch@hpe.com \
--cc=hpa@zytor.com \
--cc=jiang.liu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=rwright@hpe.com \
--cc=scott.norton@hpe.com \
--cc=tglx@linutronix.de \
--cc=waiman.long@hpe.com \
--cc=x86@kernel.org \
/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.