Date: Sat, 08 Nov 2008 19:16:06 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Kevin Oberman <oberman@es.net> Cc: Sam Leffler <sam@freebsd.org>, "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com>, Ian Smith <smithi@nimnet.asn.au>, freebsd-mobile@freebsd.org Subject: Re: RFC: powerd algorithms enhancements Message-ID: <4915C956.8090509@FreeBSD.org> In-Reply-To: <20081108160342.0F91945010@ptavv.es.net> References: <20081108160342.0F91945010@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4915C956.8090509>