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
_______________________________________________
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"
