linux-kernel - RE: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <27240C0AC20F114CBF8149A2696CBE4A01E5B70B@SHSMSX101.ccr.corp.intel.com>
Date:	Thu, 14 Aug 2014 13:57:49 +0000
From:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Liu, Changcheng" <changcheng.liu@...el.com>,
	"Wang, Xiaoming" <xiaoming.wang@...el.com>,
	"Chakravarty, Souvik K" <souvik.k.chakravarty@...el.com>
Subject: RE: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS
 back to DEFAULT



> -----Original Message-----
> From: Daniel Lezcano [mailto:daniel.lezcano@...aro.org]
> Sent: Thursday, August 14, 2014 9:30 PM
> To: Peter Zijlstra
> Cc: Liu, Chuansheng; Rafael J. Wysocki; linux-pm@...r.kernel.org; LKML; Liu,
> Changcheng; Wang, Xiaoming; Chakravarty, Souvik K
> Subject: Re: [PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS
> back to DEFAULT


> I think the main issue here is to exit the poll_idle loop when an IPI is
> received. IIUC, there is a pm_qos user, perhaps a driver (Chuansheng can
> give more details), setting a very short latency, so the cpuidle
> framework choose a shallow state like the poll_idle and then the driver
> sets a bigger latency, leading to the IPI to wake all the cpus. As the
> CPUs are in the poll_idle, they don't exit until an event make them to
> exit the need_resched() loop (reschedule or whatever). This situation
> can let the CPUs to stand in the infinite loop several seconds while we
> are expecting them to exit the poll_idle and enter a deeper idle state,
> thus with an extra energy consumption.
> 

Exactly, no function error here. But do not enter the deeper C-state will bring more power
consumption, in some mp3 standby mode, even 10% power can be saved.

And this is the patch's aim here.