https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316
John Baldwin <j...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|Needs Triage |In Discussion
CC| |j...@freebsd.org,
| |j...@freebsd.org,
| |m...@freebsd.org
--- Comment #2 from John Baldwin <j...@freebsd.org> ---
Alexander added the Intel CPUID checks in
http://svnweb.freebsd.org/base?view=revision&revision=185460
Jung-uk added the AMD CPUID check in
http://svnweb.freebsd.org/base?view=revision&revision=184146
I think there is some confusion as to what it means to be invariant. The now
official definition is "C-, P-, and T-state" invariant. However, the
'tsc_is_invariant' variable only includes 'P- and T-state' invariant, and the
system even copes with this by disabling Cx states if the TSC is used when it
is not C-state invariant.
In terms of what is in the SDM, this is how Intel defines an Invariant TSC in
the February 2014 version of Volume 3 of the SDM includes this quote about the
availability of an Invariant TSC:
17.13.1 Invariant TSC
The time stamp counter in newer processors may support an enhancement, referred
to as invariant TSC. Processor’s support for invariant TSC is indicated by
CPUID.80000007H:EDX[8].
The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states.
This is the architectural behavior moving forward. On processors with invariant
TSC support, the OS may use the TSC for wall clock timer services (instead of
ACPI or HPET timers). TSC reads are much more efficient and do not incur the
overhead associated with a ring transition or access to a platform resource.
However, earlier in the text a separate section notes the CPUs that support a
P-state invariant (constant-rate) TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
The internal processor clock cycle is determined by the current core-clock to
bus-clock ratio. Intel® SpeedStep® technology transitions may also impact the
processor clock.
• For Pentium 4 processors, Intel Xeon processors (family [0FH], models [03H
and higher]); for Intel Core Solo and Intel Core Duo processors (family [06H],
model [0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo
processors (family [06H], model [0FH]); for Intel Core 2 and Intel Xeon
processors (family [06H], DisplayModel [17H]); for Intel Atom processors
(family [06H],
DisplayModel [1CH]): the time-stamp counter increments at a constant rate. That
rate may be set by the maximum core-clock to bus-clock ratio of the processor
or may be set by the maximum resolved frequency at which the processor is
booted. The maximum resolved frequency may differ from the maximum qualified
frequency of the processor, see Section 18.14.5 for more detail. On certain
processors, the TSC frequency may not be the same as the frequency in the brand
string.
The specific processor configuration determines the behavior. Constant TSC
behavior ensures that the duration of each clock tick is uniform and supports
the use of the TSC as a wall clock timer even if the processor core changes
frequency. This is the architectural behavior moving forward.
I think the problem is that you probably have C1E enabled and so we are not
setting 'cpu_can_deep_sleep' in your case. We have special magic for C1E on
AMD, but not Intel. And even then, the special magic results in us turning off
the power savings of C1E so it becomes a dumb C1 (as well as explicitly disable
C3 from being used).
I expect most Intel CPUs of this vintage are probably using C1E by default
(since it defaults to on in the BIOS), so I would be inclined to basically go
with this patch (but without the AMD changes) and to also remove the
TC_FLAGS_C3STOP flag since it will no longer be used (and corresponding code in
tc_windup()). This will leave the 'deep_sleep' stuff as only applying to the
LAPIC timer and not to the TSC.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
