Date: Sat, 08 Nov 2008 12:05:22 -0800 From: "Kevin Oberman" <oberman@es.net> To: Alexander Motin <mav@FreeBSD.org> 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: <20081108200522.C3E0F45010@ptavv.es.net> In-Reply-To: Your message of "Sat, 08 Nov 2008 19:16:06 %2B0200." <4915C956.8090509@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1226174722_50993P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 08 Nov 2008 19:16:06 +0200 > From: Alexander Motin <mav@FreeBSD.org> > > 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. Actually, it's worse than that. They actually don't change either frequency or voltage. They simply stall the CPU for between 1 and 7 clock cycles out of every 8. The actual frequency is never changed. But it is true that they don't cut power consumption at idle and don't really result in any real economy under even partial load. My tests show a power consumption at full CPU load decreases in exact tandem with performance. (This was NOT a surprise.) So CPU intensive operations simply ran longer, but used exactly the same amount of power. No win at all. Under moderate loads, such as playing video or music, I hoped to see a real win, but powerd kept the CPU speed way too high in these cases and, again, not much gain. Bu forcing the TCC to a level where the CPU was loaded to about 75% of max, I could get a win, but I really don't see it as worthwhile. It really saved little. > > 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. I'd need to do more testing "modern" hardware to verify this, but I think you are probably right. All of the systems I have tested on are uniprocessors, none less than 2 years old. (I last did testing on this about 2 years ago.) I really should have tried to take the effects of Cx states into account, but all of the testing was done with processor states disabled (hw.acpi.cpu.cx_lowest=C1). > > 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. No argument. EST is a very real win, either at idle or under load. It is a huge win for moderate, ongoing loads like video or music. > > 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. I think we are in pretty complete agreement. Testing this sort of thing is tricky and complex. Due to newer capabilities, the testing I did would need a lot of re-design to provide good data on modern systems. It should also look at the impact of Cx states. I'd also like a good reference on c1e as I don't really understand what it does, only that it is an extension to C1 state that improves power economy without the penalties of deeper sleep states. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1226174722_50993P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFJFfECkn3rs5h7N1ERAharAKCRjYY4N6c95/qCCzHKb1Tlj632zgCfQJXA 0WX5AqDMB7PlM4YWcou+/sA= =foGV -----END PGP SIGNATURE----- --==_Exmh_1226174722_50993P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081108200522.C3E0F45010>