Date: Fri, 08 Apr 2011 20:52:24 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Daniel Gerzo <danger@FreeBSD.org> Cc: stable@FreeBSD.org Subject: Re: powerd / cpufreq question Message-ID: <4D9F4B58.3050104@FreeBSD.org> In-Reply-To: <85cda6f83d328e67a552b2cd5758dbd3@rulez.sk> References: <4D9EEDAF.3020803@rulez.sk> <4D9EF48C.9070907@FreeBSD.org> <e229a6a374fdd5a626c0b777752fef54@rulez.sk> <4D9F2384.5000104@FreeBSD.org> <85cda6f83d328e67a552b2cd5758dbd3@rulez.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08.04.2011 19:53, Daniel Gerzo wrote: > On Fri, 08 Apr 2011 18:02:28 +0300, Alexander Motin wrote: >>> OK, I understand what you are saying here. On the other side, I know >>> pretty well how the load is distributed - in this particular case, the >>> box is a web server, running ~30 php-cgi processes. >>> This kind of operation doesn't require very high frequency and I suspect >>> the cores are never waiting for each other. There could be an option >>> which would allow an administrator to decide whether this is the case >>> and allow him to set a higher -r and -i values, what do you think? >> >> I think it should be possible with minimal changes. > > 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. >>> Any idea what I should look for in the BIOS? >> >> Something about C-states, or Cx-states on the CPU page. But first >> look at dev.cpu.X.cx_supported to make sure it is not already present >> and just unused. > > 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. >>> 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. >>>> You may want to look here: >>>> http://wiki.freebsd.org/TuningPowerConsumption >>> >>> From reading this, are you reffering above to the C2 states? (seems >>> like C3 is not optimal for this kind of operation...) >> >> The deeper state, the more power saved. To get most of it and to get >> TurboBoost working you need at least C3 CPU state (ACPI may report it >> with different number). Some latest Intel CPUs have no described >> problems with C3 and LAPIC, for others described system tuning >> requited. > > I believe this is pretty recent CPU (6 core Xeon X5650). Do you know > about any problems? I have no idea about these Xeons. I know just that LAPIC of the my Core i5 works fine in C3, while one of the my Core i7 doesn't. >> PS: Using powerd in best case wont hurt performance, while using >> C-states may even increase it in some cases because of TurboBoost. > > If I want to use C-states, should I stop to use powerd, or is it > possible to use them both together? I am using both together on my laptop. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9F4B58.3050104>