Date: Sat, 09 Apr 2011 17:14:52 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Daniel Gerzo <danger@FreeBSD.org> Cc: stable@FreeBSD.org Subject: Re: powerd / cpufreq question Message-ID: <4DA069DC.3030306@FreeBSD.org> In-Reply-To: <4DA01168.8050704@FreeBSD.org> References: <4D9EEDAF.3020803@rulez.sk> <4D9EF48C.9070907@FreeBSD.org> <e229a6a374fdd5a626c0b777752fef54@rulez.sk> <4D9F2384.5000104@FreeBSD.org> <85cda6f83d328e67a552b2cd5758dbd3@rulez.sk> <4D9F4B58.3050104@FreeBSD.org> <4DA01168.8050704@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09.04.2011 10:57, Daniel Gerzo wrote: > 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? Move checks after the loop? Just an idea. > Do you mean the values around lines of 730 - 762? Yes. When load is more the twice higher then limit - frequency rises faster. To make it work with limit > 50%, there is hardcoded additional check for 95% level. > 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... It is intended behavior in hiadaptive mode, where performance is preferable to power-saving. >>> 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. I wasn't mentioning timecounter there. In terms of 9-CURRENT I was talking about eventtimer. In 8-STABLE it is not formalized yet and so the guide mentions number of tunables. > How do I know the C3 is active? sysctl dev.cpu.X.cx_usage > And how does it switch back to C1 for example? When CPU is idle, depending on previous idle statistics, system puts it into one of reported and allowed C-states. CPU goes back to C0 state on any hardware interrupt. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DA069DC.3030306>