Date: Sat, 09 Apr 2011 21:28:20 -0700 From: "Kevin Oberman" <oberman@es.net> To: Daniel Gerzo <danger@FreeBSD.org> Cc: Alexander Motin <mav@FreeBSD.org>, stable@FreeBSD.org Subject: Re: powerd / cpufreq question Message-ID: <20110410042820.CE8381CC0D@ptavv.es.net> In-Reply-To: Your message of "Sat, 09 Apr 2011 09:57:28 %2B0200." <4DA01168.8050704@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 09 Apr 2011 09:57:28 +0200 > From: Daniel Gerzo <danger@FreeBSD.org> > Sender: owner-freebsd-stable@freebsd.org > > On 8.4.2011 19:52, Alexander Motin wrote: > > >> So, here is my attempt to implement it: > >> http://danger.rulez.sk/powerd.diff > >> Can you please review & comment? I should be able to commit it mysqlf if > >> you consider it acceptable. It seems to work for me :) > > > > Looks fine, except that -f option have to be the first, that is not > > obvious. Another moment -- I've noticed some load constants hardcoded > > there. They should also be handled to make higher values to work properly. > > I tried to be more explicit in the error message which tries to emphasis > the need to put it first. I don't know myself how it would be possible > to code it so that the -f doesn't need to be first. Ideas? > > Do you mean the values around lines of 730 - 762? > > From what I have observed, if I have a machine that is a little more > loaded (say 300%) and the load goes up, it tries to increases the > performance to quite high freq (5336) and when the load decreases again, > it takes quite a while to go down from 5366 to a frequency that is > actually available to decrease the performance (something less than > 2934). So the lower frequency is used for too short time because it > takes too much time to get it... > > >> Seems like it was enabled by default. I have like these: > >> dev.cpu.0.cx_supported: C1/3 C2/96 C3/128 > >> > >> Does that mean I only need to set these in rc.conf?: > >> performance_cx_lowest="C3" > >> economy_cx_lowest="C3" > >> > >> Then run /etc/rc.d/power_profile 0x00? > > > > It short - yes. In long - read the link I've given. > > > >> May it cause any instability? > > > > It you won't switch from LAPIC to other timer and it stop - your system > > will freeze, or at least not work well. You should notice problems > > immediately, if there are. > > So I will also need to change the kern.timecounter.hardware to i8254? I > suppose it will cause a little less precise time, but should I expect > lower performance? I don't care that much about the time accuracy. > > How do I know the C3 is active? And how does it switch back to C1 for > example? > > >>>> This is 8-STABLE, any idea whether there's a MFC plan for the extra > >>>> 9-CURRENT bonuses? > >>> > >>> I suppose around May. > >> > >> Do you have some patches? If not you don't really need to make them just > >> for me, I can wait a little. > > > > Last ones I've generated are five months old: > > http://people.freebsd.org/~mav/timers_merge/ > > They are large and I am not sure how good they apply now. > > I guess I will just stick with vanilla 8-stable and then update. > > >>>>> You may want to look here: > >>>>> http://wiki.freebsd.org/TuningPowerConsumption I would like to emphasize that simple frequency reductions through throttling and TCC really don't save power. EST, which actually does change the CPU clock AND voltage, is a win, but not a big one. I you want to reduce power, deeper sleep states are the only way to go further. Dr. Tajana Rosing of the UC-San Diego System Energy Efficiency Lab has presented research that shows that servers save by far the most power when a process gets in, runs at maximum speed and gets out to allow the system to sleep. This is clearly the only way to significantly improve power consumption in servers. If you don't enable and use S3 and better (when present), you are not being power efficient. To do this, the clock must rise very quickly and should drop slowly. And even then, it's not likely to save much power or reduce heat load significantly . -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110410042820.CE8381CC0D>