powerd doesn't decrease CPU frequency in some cases
rpaulo at fnop.net
Tue Dec 25 07:55:31 PST 2007
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_,
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).
> 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
More information about the freebsd-acpi