x86: Probe the TSC frequency earlier
ClosedPublic
Actions

Authored by markj on Feb 24 2022, 9:03 PM.

Details

Reviewers

emaste
kib
jhb
cperciva

Commits

rG84369dd52369: x86: Probe the TSC frequency earlier

Summary

This lets us use the TSC to implement early DELAY on modern systems,
limiting the use of the sometimes-unreliable 8254 PIT.

PR: 262155

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 44578
Build 41466: arc lint + arc unit

Event Timeline

markj created this revision.Feb 24 2022, 9:03 PM

Herald added subscribers: rpokala, imp. · View Herald TranscriptFeb 24 2022, 9:03 PM

markj requested review of this revision.Feb 24 2022, 9:03 PM

Harbormaster completed remote builds in B44569: Diff 103205.Feb 24 2022, 9:03 PM

markj edited the summary of this revision. (Show Details)Feb 24 2022, 9:14 PM

If the concern is systems where the i8254 doesn't work, should we change tsc_freq_8254 to be more robust?

In D34367#778400, @cperciva wrote:

If the concern is systems where the i8254 doesn't work, should we change tsc_freq_8254 to be more robust?

On such systems we aren't using the 8254 to calibrate the TSC at all, we get the frequency, or something close to it, from CPUID leaves. The problem I want to address is that DELAY() (e.g., during atkbd probe) uses the 8254 timer until the (early) TSC frequency is known. I can't see any reason not to move early TSC calibration so that it happens even earlier.

This addresses the long delay I experienced on the Framework laptop at the start of boot.

In D34367#778401, @markj wrote:

In D34367#778400, @cperciva wrote:

If the concern is systems where the i8254 doesn't work, should we change tsc_freq_8254 to be more robust?

On such systems we aren't using the 8254 to calibrate the TSC at all, we get the frequency, or something close to it, from CPUID leaves.

If you're sure the combination of "broken i8254" and "old CPU" will never happen, sure.

The problem I want to address is that DELAY() (e.g., during atkbd probe) uses the 8254 timer until the (early) TSC frequency is known. I can't see any reason not to move early TSC calibration so that it happens even earlier.

Right, this definitely makes the situation better. If we do run into systems which combine older CPUs with broken i8254s we might want to change tsc_freq_8254 as well, but for now I think it's good to go ahead with this patch.

In D34367#778417, @cperciva wrote:

In D34367#778401, @markj wrote:

In D34367#778400, @cperciva wrote:

If the concern is systems where the i8254 doesn't work, should we change tsc_freq_8254 to be more robust?

On such systems we aren't using the 8254 to calibrate the TSC at all, we get the frequency, or something close to it, from CPUID leaves.

If you're sure the combination of "broken i8254" and "old CPU" will never happen, sure.