Powerd and est / eist functionality

[John Long]

At 10:35 PM 3/26/2010, Ian Smith wrote:
 >On Fri, 26 Mar 2010, Jeremy Chadwick wrote:
 >
 >[ leaving the MB monitoring stuff alone for your expert attention :-]
 >
 > > > 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.
 > >
 > > ...and this would fall under the est(4) subset driver for cpufreq(4).
 >
 >Just checking, I know nothing about these so far, but are you suggesting
 >that John having C1E and C2E enabled in BIOS may be affecting ACPI/EST
 >detection, and that things may be different were these disabled?

No sir. Detection appears to be a function of the signals that are provided 
by the mbd regardless of bios settings. As per earlier msgs, I originally 
found out that powerd actually increased the TDP of the system at the wall 
by about 3 watts. That turning off the bios settings for c1e, c2e and eist 
raised the power a little and with powerd it was still higher than with 
just bios factors on and no powerd. All the rest is just discovery as to 
why this anomaly was so. It seems that ACPI is just not fully functional 
for this motherboard and if est does work on other recent mbds then that 
would be because of the acpi working better for them as the hard coded est 
tables are a bit old. From what I see, est takes tables primary and acpi 
fallback. powerd takes est primary and thermal fallback (acpi may be in 
there too, forgot now). powerd and thermal is not viable for lowering power 
usage at very low cpu rates. It merely provides a phantom crutch until one 
does realize it does not truly work, in my case anyway. We need to use the 
P-states which lower voltage and true freq, in order to lower tdp 
sucessfully, from what I see.

 >
 >If that's not what you meant, could you expand a little?
 >
 >John: you may want to explore where this comes together in kern_cpu.c
 >where you'll see those cpufreq debugging messages you quoted.

kern_cpu.c looks to be the mech for reading or setting the freq. In there 
they mention that using an absolute freq is preferable to the artificial 
freq with lengthened clocks because then the voltage is often changed 
relative thereto. Where the voltage is changed is my quest. No where in 
there nor src/sys/kern do I see a ref for p-states and only in that file is 
voltage referenced. Therefore the change in voltage as a function of 
frequency must be auto determinant in another place and probably the bios 
as my guess so far.

Further looking I see ichss.c in /usr/src/sys/dev/cpufreq  (dev not i386 
dir) where voltage is referenced. No other refs of votage I notice other 
than batt etc and no ref to pstate nor p-state at all in src/sys. 
Personally, I deem p-states to be key therefore I may assume that they are 
left to lower level bios routines relative to freq unless I am missing 
something here. Considering the absolute freq is preferred over the 
artificial freq, that is a remnant of powerd (when it falls back to just 
thermal), and appears to be a requisite for the lower level routines in 
order to change p-states, leads me back to getting est to load proper. 
Therefore I should pursue the tables part of its detection, if I continue 
digging into things that are over my head..

   Some of
 >the more gritty documentation may be found browsing with something like:
 >% less /sys/{sys,kern,amd64/include}/*cpu*.[ch]

Things that should be left to the pros that have been wading this ocean of 
code for years.. :-)

thanks again,

John

 >
 >cheers, Ian