* Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner <t...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
