Disable sleep states on P7+
deepthi at linux.vnet.ibm.com
Wed Jan 15 22:02:53 EST 2014
On 01/14/2014 08:06 PM, Steven Pratt wrote:
> I am looking for info on when and how we are able to disable power saving features of current (P7, P7+) chips in order to reduce latency. This is often done in latency sensitive applications when
power consumption is not an issue. On Intel boxes we can disable
P-state frequency changes as well as disabling C-State or sleep state
changes. In fact we can control how deep a sleep the processor can go
I know we have control Dynamic Processor Scaling and Idle Power Savings,
but what states do these really affect? Can I really disable Nap mode
of a processor? If so how? Can I disable even the lightest winkle mode?
Looking for current information (read RHEL 6 and SLES11), future changes
On POWERVM platforms idle states currently supported are:
Snooze - reducing thread priority.
Snooze and Nap can be controlled through in-band kernel mechanisms and
Sleep state through AEM.
Currently you can turn off Idle Power Savings mode and run in dynamic
processor scaling mode. By doing so you will disable entry into Sleep
state on all CPUS.
If you further want to disable NAP, then you could just boot the kernel
with powersave=off. This will disable the entry into any of the idle
state like nap and just reduce the priority of the thread when there is
no work to be done. This is part of cpuidle framework which is available
on SLES 11 SP3 and RHEL7.
In the newer kernels cpuidle framework is adopted for POWERVM platform
but in case if you are using RHEL 6 or SLES 11 SP1/2, then you could use
the ppc64_cpu util and set a high smt-snooze-delay value say 1000.first
#> ppc64_cpu --smt-snooze-delay=1000.
smt-snooze-delay variable potentially delays entry to NAP state.
So if the idle time predicted on a cpu = 1000us and smt-snooze-delay is
set to 100 (which is default value), then on RHEL 6 and SLES 11 SP1/2
kernels cpus would reduce the thread priority and spin for first 100us
and if the cpu continues to be idle further then automatically go to NAP
state for remaining (1000-100us) time.
By setting a very high value, one would always be looping This could
potentially delay ure entry to NAP state and effectively disable entry
into NAP state most of the time.
Please let me know if you have any queries around it.
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
More information about the Linuxppc-dev