On Fri, 08 Apr 2011 14:42:04 +0300, Alexander Motin wrote:
Hello Alexander, thanks for quick reply;
root@[s1-a ~]# powerd -v -r 1000 -i 600
powerd: 1000 is not a valid percent
Well, that makes sense, but why powerd itself knows about load >
100%
but doesn't allow me to specify it? Is this bug? I suppose not if it
works for other people...
It is reasonable limitation. powerd can't know how load distributed
among multiple cores in time. If all cores are equally busy at lets
say 10% (that gives 120% total) and cores are never waiting for each
other then obviously frequency could be reduced. But if the same 120%
mean 100%+20%, or if load is equally spread, but processes on
different cores are waiting for each other, then reducing frequency
will reduce performance. powerd can't know that and so stays on a
safe
side.
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?
Other question would be why powerd wants to set freq 5336, when it
is
not available at all (would be nice to have it heh.):
You may see there it is a "wanted" frequency, not real one. :) It is
internal implementation details. In such way powerd implements
keeping
a full frequency for some time after the load dropped. It's not a
bug.
OK :-) I actually though powerd always honors the values from
dev.cpu.0.freq_levels (and 5336 is not there), so it looked a little
weird to me.
On multi-core systems like this power management can better be done
on per-core bases. Powerd can't control frequencies on per-core basis
(also because it require non-trivial interoperation with scheduler).
But if your ACPI BIOS allows, you can try to put unused cores into
deeper C-states, that may give better power saving and TurboBoost on
busy cores as a bonus. It works better on 9-CURRENT, but on 8-STABLE
some bonuses still could be achieved.
Any idea what I should look for in the BIOS?
This is 8-STABLE, any idea whether there's a MFC plan for the extra
9-CURRENT bonuses?
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...)
Thanks.
--
Kind regards
Daniel
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
