Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1157116 > unrolled thread

Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC] x86, tsc: Allow for high latency in  quick_pit_calibrate() Ingo Molnar <mingo@kernel.org> - 2015-06-03 08:30 +0200
    Re: [PATCH RFC] x86, tsc: Allow for high latency in  quick_pit_calibrate() Thomas Gleixner <tglx@linutronix.de> - 2015-06-03 18:50 +0200
      Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() Linus Torvalds <torvalds@linux-foundation.org> - 2015-06-03 19:10 +0200

#1157116 — Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > Is there really no smarter way to figure out the TSC frequency on
> > modern systems?
> 
> Sadly, if there is, we have yet to find it.
> 
> I don't think the mentioned intel_pstate thing gets it right either. Yes, it 
> gets some "theoretical frequency", given the pstate and the scaling factor, but 
> that assumes the base clock (BCLK) is something trustworthy. That's a big 
> assumption, and I can pretty much guarantee it's not a valid assumption.
> 
> I'm sure that's the *common* case, but how much do you want to bet that some 
> motherboard makers noticed that they get good press from good benchmark numbers, 
> and that they can tweak BCLK a bit higher than the competition? "Oooh, 
> motherboard from Xyz is really good, it's 1% faster than the competition".
> 
> Or all those overclockers? Yes, some of them buy unlocked CPU's and leave BCLK 
> alone. Or maybe they do both. Or maybe they just buy locked CPU's and tweak 
> BCLK.
>
> The only *well-defined* clock in a modern PC seems to still remain the PIT. 
> [...]

and the HPET, which is pretty good as well, when available. In fact given that 
it's required to have a frequency of at least 10 MHz, and (unlike the PIT) has a 
pretty wide counter, it could be used for pretty accurate calibration as well that 
runs a lot shorter than PIT calibration.

HPETs have some quirks, and are sometimes emulated (on early hardware, when Window 
did not require HPET and the value of HPET was yet unclear?), but I'd say on 
modern x86 systems it ought to be a pretty good clock for calibration as well.

> [...] Yes, it's very sad.  But all the other clocks tend to be untrustworthy for 
> various reasons, like "frequency is stated in the ACPI tables", which we know is 
> basically just a fantasy that may be right *most* of the time, but I can almost 
> guarantee that some BIOS guys decided that they can get slightly better random 
> benchmark numbers by "tweaking" the truth a bit. It's the "BIOS version" of 
> overclocking by increasing BCLK - lie about the PM frequency, so that any 
> benchmark that times things that way will give better numbers..

So the HPET frequency comes straight from a hardware register, via:

        hpet_period = hpet_readl(HPET_PERIOD);

now you are right that the 'hardware' is in some cases is implemented via SMM 
virtualization - but so is the PIT I suspect. Given that Windows relies on the 
HPET for timekeeping, it might get more attention than the PIT?

> But pretty much nobody messes up the PIT. That will change, just because it's 
> clearly getting to the point where people are just emulating it, and it's 
> probably not going to be any more trustworthy than anything else.

So I think the reason why these tend to be real hardware most of the time is that 
both the PIT and the HPET are supposed to generate interrupts - which is not that 
easy to 'emulate' via SMM: you have to have a real irq-generating clock in the 
hardware _somewhere_, and that comes with counter and all, so not much left to 
emulate after that point.

What I think might happen is to emulate the PIT via HPET, the lower frequency 
clock with a higher frequency clock.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1157840

On Wed, 3 Jun 2015, Linus Torvalds wrote:
> On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar <mingo@kernel.org> wrote:
> > Given that Windows relies on the
> > HPET for timekeeping, it might get more attention than the PIT?
> 
> Does Windows actually do that? Becuase if so, that's just about the
> strongest argument for HPET there is - it's likely to work, and the
> frequency is likely to be correct.

At least it used to. Not sure if it still does. 
 
> We've had issues with HPET, but for calibration it might very well be
> the right thing to do.

Right. The issues we had were on the clock events side caused by the
match register delayed writes. I've never seen a bug report about the
frequency being completely wrong, except for crap values which we
filter out. Though, HPET period can be off by more than 500ppm, but I
don't think that matters anymore for timekeeping as we switch to TSC
only after the long term calibration. The quick calibration is just
for getting the TSC frequency roughly correct for udelay.

> Does anybody know what the base oscillator for HPET tends to be? Also,

The most common frequency is 14.318180 MHz.

> some googling shows a vmware paper that is not that impressed with the
> HPET.

Yeah, they complain about period being off by 600ppm and therefor
being useless for timekeeping, but that's not what we want to use it
for.
 
> The good thing about the PIT is that it's just *specified* to be
> driven off a real crystal running at a very fixed frequency. There's
> no gray areas there. Sure, virtualization can screw it up (but will
> likely screw up other higher-resolution clocks even more), and hw
> designers can cause problems, but it's been pretty reliable.

The other known frequency clock is pmtimer. We use hpet and pmtimer in
the slow calibration fallback already.
 
> (Yeah, the CMOS RTC clock should be too, as George Spelvin points out.
> That might be worth looking at too).

Indeed.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1157873 — Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate()

On Wed, Jun 3, 2015 at 9:47 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> Does anybody know what the base oscillator for HPET tends to be? Also,
>
> The most common frequency is 14.318180 MHz.

I was more thinking along the lines of "which actually crystal is
driving it" than the frequency.

That said, that particular frequency does give a clue. That's exactly
12x the PIT frequency. So they presumably share the same basic
crystal, just different PLL's.

Which is a good indication that we should get very similar clock
stability with the HPET as with the PIC.

We might even use that kind of knowledge to decide "ok, let's use the
HPET as the reference clock". IOW, only use the HPET if we find it
listed, _and_ we get the expected frequency from the HPET_PERIOD
register.

Anybody who gives odd HPET_PERIOD values is likely doing somehing
different and possibly questionable.

            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web