[RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states

Preeti U Murthy preeti at linux.vnet.ibm.com
Fri Jul 26 23:11:38 EST 2013


Hi Li,

On 07/26/2013 03:35 PM, Li Yang-R58472 wrote:
> 
> 
>> -----Original Message-----
>> From: linux-pm-owner at vger.kernel.org [mailto:linux-pm-
>> owner at vger.kernel.org] On Behalf Of Preeti U Murthy
>> Sent: Thursday, July 25, 2013 5:03 PM
>> To: benh at kernel.crashing.org; paul.gortmaker at windriver.com;
>> paulus at samba.org; shangw at linux.vnet.ibm.com; galak at kernel.crashing.org;
>> fweisbec at gmail.com; paulmck at linux.vnet.ibm.com; michael at ellerman.id.au;
>> arnd at arndb.de; linux-pm at vger.kernel.org; rostedt at goodmis.org; rjw at sisk.pl;
>> john.stultz at linaro.org; tglx at linutronix.de; Zhao Chenhui-B35336;
>> deepthi at linux.vnet.ibm.com; geoff at infradead.org; linux-
>> kernel at vger.kernel.org; srivatsa.bhat at linux.vnet.ibm.com;
>> schwidefsky at de.ibm.com; svaidy at linux.vnet.ibm.com; linuxppc-
>> dev at lists.ozlabs.org
>> Subject: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support
>> deep idle states
>>
>> On PowerPC, when CPUs enter deep idle states, their local timers are
>> switched off. The responsibility of waking them up at their next timer
>> event, needs to be handed over to an external device. On PowerPC, we do
>> not have an external device equivalent to HPET, which is currently done
>> on architectures like x86. Instead we assign the local timer of one of
>> the CPUs to do this job.
> 
> I don't know much about the deep idle states.  But is it necessary to turn off the timer in these states?  I mean the extra work needed on the booting CPU and re-syncing Time Base after wakeup might defeat the power consumption benefit of turning off the timer.

The idle state that CPUs should enter into is chosen by the cpuidle
governor. And the target residency and the wakeup latency of the idle
states among others, are the factors considered by the governor before
choosing an idle state for a CPU. So deep idle states which have a
higher target residency and wakeup latency, but that have huge power
savings, are usually targeted by the governors when there are large
periods of idle, i.e. CPUs tend to remain idle for long.

Depending on the workload running, large periods of idle could be rare,
in which case deep idle states are not even entered into. But if the
workload is such that it is woken up occasionally to do work, with large
periods of idle in between, deep idle states are targeted. In such a
scenario, the power savings that such idle states yield is significant
to offset the overhead of the factors that you mention, which will need
to be done occasionally.

Hence for an almost completely idle system, having such deep idle states
fetches enormous power savings.

> 
> Btw, the Open PIC has an internal timer.  Can we use it as the wakeup event?

I am not aware of such a device on PowerPC. Even if there is one, it is
important to investigate what happens to it in deep idle states. If it
is intended to be switched off in one of the deep idle states, again the
idea that this patchset brings in has to be the fall-back solution.

My point is, it is good to have the timer offload framework
implementation because we cannot continue to rely on external devices
being there to aid us in situations when the local timer devices of CPUs
have to be turned off in deep idle states.

> 
> Regards,
> Leo

Regards
Preeti U Murthy



More information about the Linuxppc-dev mailing list