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