From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Adrian Hunter <adrian.hunter@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()
Date: Tue, 2 Jun 2015 21:58:26 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1506022148220.20347@nanos> (raw)
In-Reply-To: <20150602194350.GN1187@tassilo.jf.intel.com>
On Tue, 2 Jun 2015, Andi Kleen wrote:
> On Tue, Jun 02, 2015 at 12:41:27PM -0700, Andy Lutomirski wrote:
> > On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > > On Thu, 21 May 2015, Adrian Hunter wrote:
> > >
> > >> If it takes longer than 12us to read the PIT counter lsb/msb,
> > >> then the error margin will never fall below 500ppm within 50ms,
> > >> and Fast TSC calibration will always fail.
> > >
> > > So finally the legacy PIT emulation takes longer than the 30 years old
> > > hardware implementation. Progress!
> > >
> > >> This patch detects when that will happen and switches to using
> > >> a slightly different algorithm that takes advantage of the PIT's
> > >> latch comand.
> > >
> > > Is there really no smarter way to figure out the TSC frequency on
> > > modern systems?
> >
> > I just asked Len this question yesterday. intel_pstate can do it,
> > although the algorithm is a bit gross.
Well, the algorithm for that slow PIT emulation thing is definitely
not from the straight forward kind either.
> intel_pstate needs to know the model number. If you know the
> model number sure you can do a lot better (e.g. using the
> ref-clock fixed counter or some other methods)
>
> But if you don't you need something else. And at some point
> the only thing left over is the PIT.
Right, and if we dont have a way to readout the stuff because the
kernel does not yet have support for that particular model it falls
back to PIT slow path in the worst case.
That's better than having another weird calibration routine which
might be outdated with the next generation of PIT emulation. We've
been there with the HPET deferred writes already. No need to have more
of this nonsense.
It's about time that Intel gets its act together and provides a proper
architected way to figure that out. Though I fear that will require
another 15 years of yelling (IIRC that was the time it took to get a
constant frequency TSC).
Thanks,
tglx
next prev parent reply other threads:[~2015-06-02 19:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 7:55 Adrian Hunter
2015-06-01 7:57 ` Adrian Hunter
2015-06-02 13:58 ` Thomas Gleixner
2015-06-02 19:33 ` Thomas Gleixner
2015-06-02 19:41 ` Andy Lutomirski
2015-06-02 19:43 ` Andi Kleen
2015-06-02 19:58 ` Thomas Gleixner [this message]
2015-06-02 20:03 ` Andy Lutomirski
2015-06-02 20:20 ` Andi Kleen
2015-06-02 21:03 ` Thomas Gleixner
2015-06-02 23:38 ` Andi Kleen
2015-06-03 0:21 ` Andy Lutomirski
2015-06-03 0:39 ` Andi Kleen
2015-06-03 0:58 ` Andy Lutomirski
2015-06-03 3:30 ` Andi Kleen
2015-06-03 8:13 ` Adrian Hunter
2015-06-03 13:45 ` Linus Torvalds
2015-06-04 11:28 ` Adrian Hunter
2015-06-03 16:23 ` Thomas Gleixner
2015-06-22 11:21 ` Adrian Hunter
2015-06-22 13:14 ` Thomas Gleixner
2015-07-06 6:48 ` Adrian Hunter
2015-07-06 7:42 ` Thomas Gleixner
2015-06-22 14:12 ` George Spelvin
2015-07-06 7:42 ` [tip:x86/urgent] x86/tsc: Let high latency PIT fail fast " tip-bot for Adrian Hunter
2015-06-03 4:20 ` [PATCH RFC] x86, tsc: Allow for high latency " Linus Torvalds
2015-06-03 6:20 ` Ingo Molnar
2015-06-03 13:43 ` Linus Torvalds
2015-06-03 16:47 ` Thomas Gleixner
2015-06-03 17:04 ` Linus Torvalds
2015-06-03 17:50 ` H. Peter Anvin
2015-06-04 12:32 ` Ingo Molnar
2015-06-03 17:06 ` Ingo Molnar
2015-06-03 6:27 George Spelvin
2015-06-03 18:29 ` George Spelvin
2015-06-03 18:48 ` H. Peter Anvin
2015-06-03 19:07 ` George Spelvin
2015-06-04 16:38 ` George Spelvin
2015-06-04 16:52 ` Linus Torvalds
2015-06-04 17:54 ` George Spelvin
2015-06-04 18:07 ` Linus Torvalds
2015-06-05 5:52 ` George Spelvin
2015-06-05 6:16 ` Ingo Molnar
2015-06-05 5:58 ` Ingo Molnar
2015-06-05 8:24 ` George Spelvin
2015-06-05 8:31 ` Ingo Molnar
2015-06-05 20:17 ` George Spelvin
2015-06-06 21:50 ` George Spelvin
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=alpine.DEB.2.11.1506022148220.20347@nanos \
--to=tglx@linutronix.de \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=torvalds@linux-foundation.org \
--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
all inboxes | Powered by JetHome®