linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: patrickg <patrickg@supermicro.com>
To: "Brown, Len" <len.brown@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "mingo@kernel.org" <mingo@kernel.org>,
	"Du, Alek" <alek.du@intel.com>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"Tang, Feng" <feng.tang@intel.com>
Subject: Re: [RFC] x86, tsc: Add kcmdline args for skipping tsc calibration sequences
Date: Fri, 20 Jul 2018 15:27:32 -0700	[thread overview]
Message-ID: <c7582a8c-8cc1-eff3-2452-a8d42d23fea1@supermicro.com> (raw)
In-Reply-To: <1A7043D5F58CCB44A599DFD55ED4C94849A1AACF@FMSMSX126.amr.corp.intel.com>

Sorry for the delay.  Expect another large delay if you have any questions.  I'm pretty heavily context switching.

I wanted to double check to make sure that I wasn't mis-documenting and mis-remembering things.

On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration on SKX in December for several reasons.
> If you still have it enabled, you need this patch:
> 
> commit b511203093489eb1829cb4de86e8214752205ac6
>     x86/tsc: Fix erroneous TSC rate on Skylake Xeon
So, yeah.  I tested against mainline RHEL-alike elrepo builds before and I still saw the TSC running faster.

I've also tested against 3.10.0-862.6.3 which has those patches backported.

> 
> If you are referring to another platform that has CPUID-TSC calibration...
> it should still work on an over-clocked system.  Over-clocked platforms should
> use exactly the same reference crystal as non-overclocked platforms, but should
> modify the crystal/core multiplier.   If you are changing the reference
> crystal, then I believe you are using an un-supported hardware configuration,
> and my ability to support you is limited.
FYI for reference this is SKX Server.  Specifically the `gold` series procs.

Now; I'm not sure if we happen to be doing something strange in regards to changing the ref crystal.  I'll need to poke at them to figure that out.

I'm working on building something up with a lot of verbosity so that I can see if perhaps something is happening or not happening in an expected way.

  reply	other threads:[~2018-07-20 22:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13 19:19 [RFC] x86, tsc: Add kcmdline args for skipping tsc calibration sequences patrickg
2018-07-13 19:40 ` Arjan van de Ven
2018-07-13 19:54   ` patrickg
2018-07-13 19:54   ` patrickg
2018-07-14  2:40 ` Brown, Len
2018-07-20 22:27   ` patrickg [this message]
2018-07-24 19:45     ` patrickg
2018-07-26 19:21       ` patrickg
2018-08-16 17:28         ` patrickg
2018-10-25 17:12           ` patrickg
2018-10-25 18:01             ` Prarit Bhargava
2018-10-25 19:13               ` patrickg
2018-12-03 19:37                 ` Patrick Geary

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=c7582a8c-8cc1-eff3-2452-a8d42d23fea1@supermicro.com \
    --to=patrickg@supermicro.com \
    --cc=alek.du@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=feng.tang@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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 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).