linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Drake <drake@endlessm.com>
Cc: Len Brown <lenb@kernel.org>,
	x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux@endlessm.com,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: Detecting x86 LAPIC timer frequency from CPUID data
Date: Fri, 19 Apr 2019 00:30:02 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1904182359360.3174@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1904181511150.3174@nanos.tec.linutronix.de>

On Thu, 18 Apr 2019, Thomas Gleixner wrote:
> On Wed, 17 Apr 2019, Daniel Drake wrote:
> 
> > The CPUID.0x16 leaf provides "Bus (Reference) Frequency (in MHz)".
> > 
> > In the thread "No 8254 PIT & no HPET on new Intel N3350 platforms
> > causes kernel panic during early boot" we are exploring ways to have
> > the kernel avoid using the PIT/HPET IRQ0 timer in more cases, and
> > Thomas Gleixner suggested that we could use this CPUID data to set
> > lapic_timer_frequency, avoiding the need for calibrate_APIC_clock()
> > to measure the APIC clock against the IRQ0 timer.
> > 
> > I'm thinking of the the following code change, however I get
> > unexpected results on Intel i7-8565U (Whiskey Lake). When
> > booting without this change, and with apic=notscdeadline (so that
> > APIC clock gets calibrated and used), the bus speed is detected as
> > 23MHz:
> > 
> >  ... lapic delta = 149994
> >  ... PM-Timer delta = 357939
> >  ... PM-Timer result ok
> >  ..... delta 149994
> >  ..... mult: 6442193
> >  ..... calibration result: 23999

That's 24MHZ which is the nominal clock for these machines.

> >  ..... CPU clock speed is 1991.0916 MHz.
> >  ..... host bus clock speed is 23.0999 MHz.

I think that printout is wrong in two aspects. First it should be
23.9999Mhz, second it should be 100MHz. This stuff comes from old systems
which had completely different clock setups.

> > However the CPUID.0x16 ECX reports a 100MHz bus speed on this device,
> > so this code change would produce a significantly different calibration.

Yes.

> > Am I doing anything obviously wrong?
> 
> It's probably just my fault sending you down the wrong path. What's the
> content of CPUUD.0x15 on that box?

I bet that CPUID.0x15 ECX says 24Mhz or it just says 0 like on my
machine. But then interestingly enough on that box I see:

   Time Stamp Counter/Core Crystal Clock Information (0x15):
      TSC/clock ratio = 168/2
      nominal core crystal clock = 0 Hz

   Processor Frequency Information (0x16):
      Core Base Frequency (MHz) = 0x834 (2100)
      Core Maximum Frequency (MHz) = 0xed8 (3800)
      Bus (Reference) Frequency (MHz) = 0x64 (100)

Assuming that TSC and local APIC timer run from the same frequency on these
modern machines.

       2100MHz * 2 / 168 = 25MHz

and disabling the tsc deadline timer tells me:

  ..... calibration result: 24999

Close enough. Thinking about it - that makes a lot of sense. With TSC
deadline timer available it would be pretty silly if there is yet another
clock feeding into local APIC.

And the 0x15 -> 0x16 correlation is clear as well. The TSC runs at the
nominal CPU frequency, in this case 2100MHz. So the nominator/denominator
pair from 0x15 allows to deduce the nominal core crystal clock which seems
to be exactly the clock which is fed into the local APIC timer.

If someone from Intel could confirm that, then we could make that work for
any modern system.

Thanks,

	tglx

  reply	other threads:[~2019-04-18 22:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17  5:28 Detecting x86 LAPIC timer frequency from CPUID data Daniel Drake
2019-04-18 13:12 ` Thomas Gleixner
2019-04-18 22:30   ` Thomas Gleixner [this message]
2019-04-19  8:35     ` Daniel Drake
2019-04-19  8:57       ` Thomas Gleixner
2019-04-19 20:50         ` Jacob Pan
2019-04-19 20:52           ` Thomas Gleixner
2019-04-19 23:09             ` Jacob Pan
2019-05-09 10:34       ` [tip:x86/apic] x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency tip-bot for Daniel Drake
  -- strict thread matches above, loose matches on Subject: below --
2019-05-09  5:54 [PATCH v2 1/3] x86/tsc: use " Daniel Drake
2019-05-09  5:54 ` [PATCH v2 2/3] x86/apic: rename lapic_timer_frequency to lapic_timer_period Daniel Drake
2019-05-09 10:34   ` [tip:x86/apic] x86/apic: Rename 'lapic_timer_frequency' to 'lapic_timer_period' tip-bot for Daniel Drake
2019-05-09  5:54 ` [PATCH v2 3/3] x86/tsc: set LAPIC timer period to crystal clock frequency Daniel Drake
2019-05-09  7:25 ` [PATCH v2 1/3] x86/tsc: use CPUID.0x16 to calculate missing crystal frequency Thomas Gleixner
2019-05-09  9:07   ` Ingo Molnar
2019-04-03  7:49 No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot Daniel Drake
2019-04-03 11:21 ` Thomas Gleixner
2019-04-03 12:01   ` Thomas Gleixner
2019-04-09  5:43   ` Daniel Drake
2019-04-10 12:54     ` Thomas Gleixner
2019-04-16  5:21       ` Daniel Drake
2019-05-09 10:35   ` [tip:x86/apic] x86/tsc: Set LAPIC timer period to crystal clock frequency tip-bot for Daniel Drake
2019-06-27  8:54   ` No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot Daniel Drake
2019-06-27 14:06     ` Thomas Gleixner
2019-06-28  3:33       ` Daniel Drake
2019-06-28  5:07         ` 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=alpine.DEB.2.21.1904182359360.3174@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=drake@endlessm.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@endlessm.com \
    --cc=rafael.j.wysocki@intel.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 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).