public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Kasper Pedersen <kernel@kasperkp.dk>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: x86: tsc: make TSC calibration more immune to interrupts
Date: Wed, 20 Apr 2011 13:28:00 -0700	[thread overview]
Message-ID: <1303331280.2796.154.camel@work-vm> (raw)
In-Reply-To: <4DAF37B4.3040408@kasperkp.dk>

On Wed, 2011-04-20 at 21:44 +0200, Kasper Pedersen wrote:
> With the delayed workqueue patch, I see a wonderful 0.4ppm
> offset _almost_ all of the time.
> 
> Very rarely though (about 1 in 3000) the value output by
> "Refined TSC .." jumps. It can jump no further than
> 50000/F_TSC/delayed_time, so on a modern machine it jumps
> no further than 20ppm.
> 
> This can happen when a short irq occurs between
> *p = hpet_readl(HPET_COUNTER) & 0xFFFFFFFF;
> and
> t2 = get_cycles();
> 
> 
> Without the delayed workqueue patch 30ppm is insignificant.

Thanks for the additional details!

In that case, the patch seems reasonable to me.

If the additional ~200us (I suspect 100us is a little low, as acpi pm
can take ~3.5us access time * 5 * 8 = 140us) is an issue, you could
probably add a "good vs best" flag, which would decide between returning
the first value that is under the SMI_THRESHOLD vs your method of
returning the best value with the lowest uncertainty. This would allow
us to only use it in the refined calibration where the smaller noise
reduction makes a difference.

Ingo, Thomas, any other complaints?

thanks
-john



  reply	other threads:[~2011-04-20 20:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-20 18:52 x86: tsc: make TSC calibration more immune to interrupts Kasper Pedersen
2011-04-20 19:15 ` john stultz
2011-04-20 19:44   ` Kasper Pedersen
2011-04-20 20:28     ` john stultz [this message]
2011-04-20 21:22       ` x86: tsc: v2 " Kasper Pedersen
2011-04-20 22:39         ` Josh Triplett
2011-04-21  2:19           ` john stultz
2011-04-21  4:32             ` Josh Triplett
2011-04-21 19:46           ` Kasper Pedersen
2011-04-23  1:38             ` john stultz
2011-04-21 19:52           ` x86: tsc: v3 " Kasper Pedersen

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=1303331280.2796.154.camel@work-vm \
    --to=johnstul@us.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hpa@zytor.com \
    --cc=kernel@kasperkp.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox