Page MenuHomeFreeBSD

Skip TSC calibration if exact value known
ClosedPublic

Authored by cperciva on Dec 30 2021, 3:28 AM.

Details

Summary

It's possible that the "early" TSC calibration gave us a value which
is known to be exact; in that case, skip the later re-calibration.

Test Plan

Darius has a VMWARE system and has offered to test this.

This patch should result in little or no change to kern.timecounter.tc.TSC but a second of DELAY being shaved off from the boot time.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

cperciva created this revision.
cperciva added a reviewer: markj.

Darius (Daniel O'Connor) has tested and confirms that this operates as expected under VMWare -- the TSC-low timecounter is set up correctly, but the 1 second of calibration time is gone.

markj added inline comments.
sys/x86/x86/tsc.c
62

This can be qualified with static.

271

I think it'd be a bit neater to set this flag in tsc_freq_vmware().

This revision is now accepted and ready to land.Dec 30 2021, 2:02 PM
cperciva edited the summary of this revision. (Show Details)

Adjust per markj's comments

This revision now requires review to proceed.Dec 30 2021, 7:46 PM

Thanks! Does it look good now?

This revision is now accepted and ready to land.Dec 30 2021, 7:50 PM

Thanks! Does it look good now?

Looks reasonable to me, thanks. We could possibly also skip late calibration if CPUID leaf 0x15 is present, as I believe it is also supposed to provide an authoritative value.

This revision was automatically updated to reflect the committed changes.

We could possibly also skip late calibration if CPUID leaf 0x15 is present, as I believe it is also supposed to provide an authoritative value.

I wondered about that -- does 0x15 say what the frequency *is* or what the frequency *should be*? (Thinking about overclocking etc here).

I'm already planning on splitting the vmware bit so that the cpuid value from there can be used with other hypervisors -- KVM for one publishes that leaf. (Which means it's available in EC2.)

We could possibly also skip late calibration if CPUID leaf 0x15 is present, as I believe it is also supposed to provide an authoritative value.

I wondered about that -- does 0x15 say what the frequency *is* or what the frequency *should be*? (Thinking about overclocking etc here).

It provides the ratio of the TSC frequency and the "core crystal clock" frequency, as well as the nominal core crystal clock frequency. CPUID leaf 0x16, which provides the "processor base frequency," is described in the SDM with the caveat that, "Data is returned from this interface in accordance with the processor's specification and does not reflect actual values." There's no similar language in the description of leaf 0x15, so that and some reading of the DPDK and Linux code makes me think that 0x15 can be trusted to give an accurate value.