cvs commit: src/sys/amd64/amd64 cpu_switch.S machdep.c
nate at root.org
Tue Oct 18 14:38:44 PDT 2005
Poul-Henning Kamp wrote:
> In message <43553162.5040802 at root.org>, Nate Lawson writes:
>>>The TSC represents the clock rate of the CPU, and thus can vary wildly
>>>when thermal and power management controls kick in, and there is no way
>>>to know when it changes. Because of this, I think that it's
>>>practically useless on Pentium-Mobile and Pentium-M chips, among many
>>This is a myth.
> It isn't a myth.
> As recent as this year chips have been sent on the market which
> will throttle their cpu-clock and TSC on certain chip stress
> conditions without giving any timely indication to any part of
> the BIOS or OS.
Does this refer to the p4tcc platform limit that I described or is it
soemthing different? In my analysis, the limit is set very high and
should not be hit unless a fan fails. This info seems to match my
"Thermal Monitor controls the processor temperature by modulating
(starting and stopping) the processor core clocks. Automatic and
On-Demand modes are used to activate the thermal control circuit (TCC).
When automatic mode is enabled, the TCC will activate only when the
interanl die temperature is very near the temperature limits of the
For Prescott, the temp for automatic cut-in is around 72C. We may be
able to detect this on SMP systems via IPIs (I don't know which ones).
That doesn't mean we can ignore it, just that we don't have to optimize
for that case. When your CPU is about to melt down, having slower
scheduling for a few seconds doesn't seem unreasonable.
> The solution to the context switch problem is _not_ to botch
> the timekeeping, the solution is to not _need_ the timekeeping.
Yes, I agree. We need to fix context switching to not be
binuptime()-based and separately improve TSC support so it can be used
more often as a timecounter.
More information about the cvs-src