This is a discussion on Re: RFC: powerd algorithms enhancements - FreeBSD ; Kevin Oberman wrote: > While I am hardly an expert on CPU power management, I have done a lot > of testing and benchmarking and I really think that FreeBSD uses CPU > throttling and/or P4TCC lin a manner not ...
Kevin Oberman wrote:
> While I am hardly an expert on CPU power management, I have done a lot
> of testing and benchmarking and I really think that FreeBSD uses CPU
> throttling and/or P4TCC lin a manner not intended by Intel and not as
> Windows does and I think that is why we have the problem.
> TCC was designed to be used for thermal control and I suspect, though I
> have no documentation to support it, that throttling was, as well. They
> were to allow the temperature of the CPU to be kept at a safe level
> when, due to inadequate heat transfer or some other problem, a CPU could
> be getting hot enough to damage itself.
TCC affects only frequency, but not the voltage. So it reduces active
consumption together with performance. But idle consumption depends on
presence of different power-saving technologies. For example I have done
tests some time ago which show that TCC gives benefits on idle when C1E
is not present of disabled. As soon as C1E on modern CPUs anyway
disables frequency when idle, TCC is just unable to propose anything better.
> While both result in steps of 12.5% reduction in speed, for their
> designed purpose, they probably will only be used when the CPU is being
> clocked (or over-clocked) at its highest speed and will only be slowed
> by, perhaps, 25 or 37.5%, not 75 or 87.5%. Those long pauses simply
> don't work well.
From overheat protection point of view I don't see the reason why TCC
can't be combined with EST. EST is surely more effective as it also
controls CPU voltage. We should just be sure that while creating
combined frequency list we are always using lowest possible EST profile.
If it happen that due to uneven dividers we can get 200MHz using TCC
divider from some higher frequency or 300MHz by EST we should probably
prefer last one.
> SpeedStep, EST, Cool 'n' Quiet, and the like are designed for power
> management and my tests have shown them to be far more effective for
> this than throttling. I simply disable both TCC and throttling and let
> EST/Cool 'n' Quiet do the job. It seem almost as effective in reducing
> power consumption and provides better responsiveness in my systems. It
> does mean that, instead of 32 speeds, I have only 5, ranging from 2 GHz
> down to .8 Ghz, but that is quite adequate for my needs.
EST at the same time controls CPU voltage, so it effective for both
active and idle states and does not depends on C1E. Only deeper Cx sleep
states are able to give something comparing to EST on idle consumption.
> Note that this applies to newer systems. SpeedStep was not very good and
> TCC/throttling was probably needed on old systems. (It was on my old 1
> GHz P4, at least.) But modern systems seem happiest and most efficient
> when just using the tools designed for power management.
As I understand TCC is effective for CPUs without C1E support enabled.
SpeedStep and EST may also have some opponents from Cx world. So here is
a big question how can we distinguish which CPU capabilities are most
power-effective for this specific CPU?
From other point view may left kernel things as is, but teach powerd to
use only EST/C'n'Q frequencies for power saving when they are available.
EST freqs are available via sysctl now, so it's not difficult. I don't
have C'n'Q systems to check it, but it should not be a problem to make
the same there.
If we sometimes wish to do passive temperature control, we could use
full combined set of frequencies.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"