On 08.04.2011 17:42, Daniel Gerzo wrote:
On Fri, 08 Apr 2011 14:42:04 +0300, Alexander Motin wrote:
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?
I think it should be possible with minimal changes.
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.
It does it on left side, but no longer on the right side. Abstracting
from real frequencies made behavior more universal and predictable.
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?
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.
This is 8-STABLE, any idea whether there's a MFC plan for the extra
9-CURRENT bonuses?
I suppose around May.
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.
PS: Using powerd in best case wont hurt performance, while using
C-states may even increase it in some cases because of TurboBoost.
--
Alexander Motin
_______________________________________________
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"
