powerd doesn't decrease CPU frequency in some cases

[Rui Paulo]

At Tue, 25 Dec 2007 17:16:58 +1100 (EST),
Ian Smith wrote:
> 
> On Mon, 24 Dec 2007, Rui Paulo wrote:
>  > At Mon, 24 Dec 2007 23:16:54 +0200,
>  > Aragon Gouveia wrote:
>  > > 
>  > > Hi,
>  > > 
>  > > | By Rui Paulo <rpaulo at fnop.net>
>  > > |                                          [ 2007-12-24 14:43 +0200 ]
>  > > > Isn't it better to teach est(4) to ignore values that differ in, say,  
>  > > > +/- 5Mhz ?
>  > > 
>  > > I agree my patch isn't ideal.  I was thinking about it today and it might
>  > > be useful to implement something that ignores frequencies whose power
>  > > ratings don't differ by more than X mW.  In my case, both 2201 and 2200 are
>  > > rated to draw 35000 mW.  The question is, in these cases which one of the
>  > > two should be ignored?  Can't ignore both...
>  > 
>  > I think you can ignore one of them, which one doesn't really matter
>  > because the power levels are the same. I suspect that, in these cases,
>  > the 2001 comes after 2000 in the EST table, so if we ignore a value
>  > already present, 2000 will remain and 2001 will be ignored.
> 
> I'm starting to wonder if this 2000/2001 thing isn't some sort of signal
> to a Certain OS to do Something Proprietary.  As it makes no engineering
> sense, best we can do for powerd without Inside Knowledge is what both
> these patches offer, eliminating/ignoring frequencies that won't set.
> 
> It seems it does matter which is chosen; Andrey demonstrated in his case
> that setting 2000 gave 2001 anyway, so the one that reads back wrong
> when set is the one to ignore.  It'd be better to know _why_,
> though.

Well, the fact that "setting 2000 gave 2001 anyway" is most likely
regarding to how est is programmed, I think.


>  > > Sorry Andrey, I missed your patch.  Was a bit overly excited when I saw
>  > > someone else finally experiencing the same problem as me after receiving
>  > > zero response a month ago when I posted about it. :)
>  > > 
>  > > Something I asked in my post a month ago was where does
>  > > dev.cpu.X.freq_levels get its data?  I was thinking it might be something
>  > > that can be addressed with a patched ACPI DSDT?
>  > 
>  > dev.cpu.0.freq_levels is the combiation of several power/speed
>  > throttling sources, namely, est(4), acpi_throttle(4), etc. The API
>  > that deals with this is cpufreq(8).
> 
> s/8/4/
> 
> Trouble is, there exists no est(4), acpi_throttle(4) nor acpi_perf(4),
> checked again after seeing your message, up to 8-current.  Trying to
> work out interdependencies and interactions between the various modules
> and drivers is, as far as I can tell, a matter of studying the code,
> which I've done a bit at times for interest, but certainly not deeply
> enough to try documenting, nor even making a decent dependency diagram.
> 
> cpufreq(4) is about as good as it gets currently, and I gather cpufreq
> isn't dependent on ACPI as such.  I can't find manuals for ANY of these:
> 
> SUPPORTED DRIVERS
>      The following device drivers offer absolute frequency control via the
>      cpufreq interface.  Usually, only one of these can be active at a time.
> 
>      acpi_perf  ACPI CPU performance states
>      est        Intel Enhanced SpeedStep
>      ichss      Intel SpeedStep for ICH
>      powernow   AMD PowerNow! for K7 and K8
>      smist      Intel SMI-based SpeedStep for PIIX4
> 
>      The following device drivers offer relative frequency control and have an
>      additive effect:
> 
>      acpi_throttle  ACPI CPU throttling
>      p4tcc          Pentium 4 Thermal Control Circuitry
> 
> Can anyone point to any out-of-band documentation for any of this?

There are no man pages for them, I failed to check the man pages
properly.

Regards.
--
Rui Paulo