linux-kernel - Re: [linux-pm] [PATCH] cpuidle: avoid singing capacitors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080313173437.5f00f70e@mjolnir.drzeus.cx>
Date:	Thu, 13 Mar 2008 17:34:37 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Len Brown <lenb@...nel.org>
Cc:	linux-pm@...ts.linux-foundation.org, Pavel Machek <pavel@....cz>,
	LKML <linux-kernel@...r.kernel.org>,
	Adam Belay <abelay@...ell.com>,
	Andi Kleen <andi@...stfloor.org>,
	Lee Revell <rlrevell@...-job.com>
Subject: Re: [linux-pm] [PATCH] cpuidle: avoid singing capacitors

On Wed, 12 Mar 2008 15:11:17 -0400
Len Brown <lenb@...nel.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/