Date: Sat, 08 Nov 2008 08:03:42 -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: <20081108160342.0F91945010@ptavv.es.net> In-Reply-To: Your message of "Sat, 08 Nov 2008 07:19:20 %2B0200." <49152158.9090207@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1226160222_50993P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 08 Nov 2008 07:19:20 +0200 > From: Alexander Motin <mav@FreeBSD.org> > Sender: owner-freebsd-mobile@freebsd.org > > Ian Smith wrote: > > We're now seeing cpus that can vary freq, with absolute and relative > > cpufreq drivers enabled, in ratios up to 32:1 or so, so the advice, > > apart from 'disable powerd' :), seems to be to at least try setting > > cpufreq.lowest to some reasonable speed for workload, maybe 300MHz? > > I surely should not be the default, but it is reasonable if systems > should have some guarantied minimal performance. > > PS: At any modern SMP/HTT system, even if scheduler is unable to manage > this IRQ situation, powerd running on different CPU will rise clock to > required level just in second. It is hard to lock-out all CPUs same > time. It's surely not solution, but still... 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. 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. 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. 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. -- 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_1226160222_50993P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFJFbhekn3rs5h7N1ERAjQ4AKCUWol8V6gBVBoFzflNpsdyGSbM4QCffzVF dikfh32lhj/VLoNWFm/hFak= =wD7W -----END PGP SIGNATURE----- --==_Exmh_1226160222_50993P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081108160342.0F91945010>