cvs commit: src/sys/i386/cpufreq p4tcc.c
nate at root.org
Wed Feb 23 20:05:50 GMT 2005
Maxim Sobolev wrote:
> Nate Lawson wrote:
>> njl 2005-02-23 16:42:56 UTC
>> FreeBSD src repository
>> Modified files:
>> sys/i386/cpufreq p4tcc.c Log:
>> Import a rewrite of p4tcc for the cpufreq(4) framework. This includes
>> a bugfix of clearing the On-Demand flag when going back to 100%. It
> I don't think this counts as a bugfix, moreover I don't see any need for
> additional logic to do this, since clearing on-demand flag is the same
> as setting 100%. In both those cases performance is 100% and throttling
> only kicks in when CPU overheats.
The original p4tcc.c never cleared the On-Demand flag. Instead, it just
set the 3-bit field to zero in the 100% case. I'm not sure if that
worked on some systems, but on my R32, this gave the same performance as
the 12.5% setting, not 100%. However, clearing the On-Demand flag did
pull it back up to 100% performance, hence it was a bugfix. This
matches the Intel documentation in that it only mentions the user being
able to set values from 87.5% to 12.5% when On-Demand is set, no 100%
value. (In other words, a setting of 0 in On-Demand mode is undefined).
Here is the info from section 6.1.2 of the P4-Mobile datasheet:
"When using On-Demand mode to activate the TCC, the duty cycle of the
clock modulation is programmable via bits 3:1 of the same ACPI Thermal
Monitor Control register. In automatic mode, the duty cycle is fixed,
however in On-Demand mode, the duty cycle can be programmed from 12.5%
on/ 87.5% off, to 87.5% on/12.5% off in 12.5% increments."
However, this is still not perfect in that if a high thermal condition
occurs, we can be at 50% performance no matter what On-Demand is set to.
I added an XXX comment for this. In practice, a system that is
bumping up against the Automatic thermal trip point a few seconds after
boot is not going to be concerned about the announced values for cpufreq
being low by 50%.
More information about the cvs-all