On Wed, 12 Mar 2008 15:11:17 -0400
Len Brown <lenb@xxxxxxxxxx> wrote:
> > I guess the only way to find out is to disassemble the DSDT. Exposing myself to such concentrations of ACPI is not an appealing project. :/
>
> the latest cpuidle code actually publishes the details of the C-states being used.
>
> $ pwd
> /sys/devices/system/cpu/cpu0/cpuidle/state3
> $ grep . *
> desc:ACPI FFH INTEL MWAIT 0x20
> latency:17
> name:C3
> power:250
> time:1862590932
> usage:9028970
>
> You'll see "desc" change if ACPI pulls a _CST change on you.
>
It does not. But my C3 desc looks like this:
state3/desc:ACPI FFH INTEL MWAIT 0x50
What's the meaning of the last number?
I also have different latency and power:
state3/latency:162
state3/power:100
> > Disabling the second core makes the noise go away. This might be a subset of 1., as I've been told that a stopped core enters C1.
>
> if you disable it at run-time, Linux puts it in C1.
> If you never boot it in the first place (eg. maxcpusp=1), the BIOS leaves it in the deepest available C-sate.
>
Ah. Didn't know that. I've confirmed this as the noise is there when booting with maxcpus.
> >
> > So for now, the only viable workaround is processor.max_cstate....
>
> yup, that's why we put it in. Is it insufficient?
>
For some value of insufficient. It is sub-optimal. I'm hoping there is a way to enter C3 in a pattern that avoids the noise and still gives a reduced power usage.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
