Powerd and est / eist functionality

John Long fbsd2 at sstec.com
Fri Mar 26 08:20:44 UTC 2010


At 09:24 PM 3/25/2010, Ian Smith wrote:
 >On Wed, 24 Mar 2010, John Long wrote:
 > > At 11:27 PM 3/22/2010, Alexander Motin wrote:
 > > >John Long wrote:
 > > >>    Hello, I am putting together a couple update servers. Went with c2d
 > > >>    E7500 on gigabyte G41M-ES2L boards. fbsd 8.0 release generic (so 
far)
 > > >>    amd64, 1g mem, 1tb wd cavier blk, fresh system.
 > > >>    My Kill-a-watt shows 41 watts idle and when I enable powerd then it
 > > >>    climbs to 43 watts idle.
 >
 >I'm interested in this apparently strange finding.  Can you show sysctl
 >dev.cpu after boot but before running powerd, and after starting powerd?
 >
 >I wonder particularly what dev.cpu.o.freq is before running powerd, ie
 >whether it boots up at full speed?  We've seen some that haven't,
 >perhaps influenced by BIOS settings?

Bios is most recent re their site. F6 I believe. boots to same 41 watts.
%sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 2933
dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1 
733/-1 366/-1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us
%powerd -n adp

about 3 secs later
%sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1833
dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1 
733/-1 366/-1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us

wait about 10 more sec and it is down to min freq and pwr is up to 44 watts.
%sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 366
dev.cpu.0.freq_levels: 2933/-1 2566/-1 2199/-1 1833/-1 1466/-1 1099/-1 
733/-1 366/-1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 500us

 >Turning on debug.cpufreq.verbose and hw.acpi.verbose may add clues?

Either of the above makes no change in dev.cpu out but sysctl -a gets 
really noisy in places
cpufreq: dup done, inserting new level 1833 after 2199
cpufreq: expand set added rel setting 62% to 1833 level
cpufreq: dup set considering derived setting 1466
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 1466 after 1833
cpufreq: expand set added rel setting 50% to 1466 level
cpufreq: dup set considering derived setting 1099
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 1099 after 1466
cpufreq: expand set added rel setting 37% to 1099 level
cpufreq: dup set considering derived setting 733
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 733 after 1099
cpufreq: expand set added rel setting 25% to 733 level
cpufreq: dup set considering derived setting 366
cpufreq: removed last relative driver: p4tcc1
cpufreq: dup done, inserting new level 366 after 733
cpufreq: expand set added rel setting 12% to 366 level
cpufreq: setting rel freq 10000 on p4tcc1 (cpu 1)
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: get returning known freq 2933
cpufreq: adding 8 relative settings
cpufreq: adding abs setting 2933 at head
cpufreq: expand set added rel setting 100% to 2933 level
cpufreq: dup set considering derived setting 2566
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 2566 after 2933
cpufreq: expand set added rel setting 87% to 2566 level
cpufreq: dup set considering derived setting 2199
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 2199 after 2566
cpufreq: expand set added rel setting 75% to 2199 level
cpufreq: dup set considering derived setting 1833
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 1833 after 2199
cpufreq: expand set added rel setting 62% to 1833 level
cpufreq: dup set considering derived setting 1466
cpufreq: removed last relative driver: p4tcc0
cpufreq: dup done, inserting new level 1466 after 1833
cpufreq: expand set added rel setting 50% to 1466 level
cpufreq: dup set considering derived setting 1099
........

Hundreds of those lines,  Keeps repeating, fast to slow to fast etc...

 >
 > > >>    It shows that the freq is controlled well, goes down to 365 mhz but
 > > >>    the tdp is not decreased, rather it increases.
 >
 >Yes you're only getting p4tcc throttling as Alexander points out. You'll
 >need to get est working to get power reduction from lower frequencies,
 >which likely won't correspond to these f/8 step throttling frequencies.
 >
 >As Jeremy suggested, here's how to turn throttling off, and something
 >like what you could expect with est working:
 >http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html

from link:
I would recommend you to disable it by setting:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1

I get unknown oid on both. Not sure how to disable p4tcc here. What I have 
to work with.
dev.p4tcc.0.%desc: CPU Frequency Thermal Control
dev.p4tcc.0.%driver: p4tcc
dev.p4tcc.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1
dev.p4tcc.1.%desc: CPU Frequency Thermal Control
dev.p4tcc.1.%driver: p4tcc
dev.p4tcc.1.%parent: cpu1
dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1

Tried variations of dev instead of hint, no go.

going to c3 lowers it about a watt with powerd running to 43. c2 would be 
somewhere inbetween?

%sysctl -a | grep lowest
debug.cpufreq.lowest: 0
hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_lowest: C1
dev.cpu.1.cx_lowest: C1
%
%sysctl -a | grep C1
hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1 C2/1 C3/150
dev.cpu.0.cx_lowest: C1
dev.cpu.1.cx_supported: C1/1 C2/1 C3/150
dev.cpu.1.cx_lowest: C1
%
%sysctl hw.acpi.cpu.cx_lowest=C2
hw.acpi.cpu.cx_lowest: C1 -> C2

42/43 watts now
%sysctl dev.cpu.0.cx_lowest=C2
dev.cpu.0.cx_lowest: C2 -> C2
%sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C2 -> C2
no other change with above 2 lines.

%killall powerd
It drops to 41 watts while still in C2

 >
 > > >>    If I disable eist, c1 and c3 helpers in bios, as per suggestion in
 > > >>    mail archive, then it adds 1 watt to both figures. I was hoping 
to get
 > > >>    this total tdp down to a very low amount, and it is but it should
 > > >>    theoretically go lower with powerd, right?
 >
 >If powerd were actually reducing frequency (and voltage) via est it
 >certainly would.  Finding out why est is failing to attach on your
 >hardware is the only likely path to success, try focusing on that and
 >ignoring side issues.  Have you browsed freebsd-acpi archives re this?

Sounds right, I did not find the est code yet to peruse it some. Otherwise 
I am out of clues on what to do.

 > > >>    load   3%, current freq  365 MHz ( 7), wanted freq  365 MHz
 > > >>    load   0%, current freq  365 MHz ( 7), wanted freq  365 MHz
 > > >
 > > >Your ACPI BIOS seems not reporting tables required to control EIST. So
 > > >powerd probably uses only thermal throttling, which is not really
 > > >effective for power saving on modern CPUs. You should check your BIOS
 > > >options or may be update BIOS.
 > > >
 > > >If you have no luck with EIST - try to use C-states if BIOS reports at
 > > >least them. It also can be quite effective.
 > > >
 > > >--
 > > >Alexander Motin
 > >
 > > Thanks for the info, I did try to kick it to C3 and that helped poquito
 > > amount. Everything is enabled in bios that matters to this, that does 
help a
 > > little too but powerd actually raises tdp a little. See other recent reply
 > > for more info.
 >
 >Have you tried C2?  Are you running the latest BIOS?  And perhaps your
 >ACPI ASL may be amenable to repair, if Gigabyte ACPI is broken here?

Changes to the asl are a bit more than I would want to get into. If I can 
find the est code then I might dig further..

Bios is most recent, has EIST, c1e and c2e I believe enabled. That seems to 
do the best all by itself. Maybe It does no good to beat a dead horse?? 
:-)  I see an ITE IT8718F-S chip on board. mbmon does work somewhat but its 
code is way old and does not see the newer chip versions. some good docs 
with mbmon in usr/local/share/docs tho..
%mbmon -d -A
Summary of Detection:
  * ISA monitor(s):
   ** Nat.Semi.Con. Chip LM78 found.
   ** Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found

vcore is 1.14 now but most of the rest are not correct readings. It is 1.28 
without bios settings enabled.
It never gets lower. Probably if I declock it below 2.93. 1.05 is what I 
was hoping to go down to or lower at 365mhz.

%mbmon
Temp.= 191.0,  0.0,  0.0; Rot.=  874, 3358, 2657
Vcore = 1.14, 1.92; Volt. = 3.31, 4.92,  1.09, -14.19, -6.12

Temp.= 191.0,  0.0,  0.0; Rot.=  874, 3358, 2657
Vcore = 1.15, 1.92; Volt. = 3.31, 4.92,  1.09, -14.19, -6.12
%
%powerd -n adp
%mbmon
Temp.= 191.0,  0.0,  0.0; Rot.=  874, 3358, 2657
Vcore = 1.18, 1.92; Volt. = 3.31, 4.92,  1.22, -14.19, -6.12

Temp.= 191.0,  0.0,  0.0; Rot.=  874, 3358, 2657
Vcore = 1.14, 1.92; Volt. = 3.31, 4.92,  1.16, -14.19, -6.12

It jumped up in vcore a little there with powerd. C1E and C2E which include 
P-states are what I am really after and I think that the bios by itself 
provides those changes better than any other changes in these settings.

 >
 >cheers, Ian

Thanks to everyone that responded.

John



More information about the freebsd-stable mailing list