Date: Tue, 25 Dec 2007 17:16:58 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Rui Paulo <rpaulo@fnop.net> Cc: freebsd-acpi@freebsd.org Subject: Re: powerd doesn't decrease CPU frequency in some cases Message-ID: <Pine.BSF.3.96.1071225162027.20757A-100000@gaia.nimnet.asn.au> In-Reply-To: <863atrfyhh.wl%rpaulo@fnop.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
> > 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?
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1071225162027.20757A-100000>