All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carsten Emde <C.Emde@osadl.org>
To: Rafael Wysocki <rjw@sisk.pl>
Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>,
	Len Brown <len.brown@intel.com>, Kevin Hilman <khilman@ti.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PM mailing list <linux-pm@vger.kernel.org>,
	Carsten Emde <C.Emde@osadl.org>
Subject: [PATCH 1/1 v3] Honor state disabling in the cpuidle ladder governor
Date: Thu, 19 Jul 2012 22:34:10 +0200	[thread overview]
Message-ID: <20120719204338.905308004@osadl.org> (raw)
In-Reply-To: 20120719203409.398114351@osadl.org

[-- Attachment #1: drivers-cpuidle-ladder-honor-disabling-with-doc.patch --]
[-- Type: text/plain, Size: 3730 bytes --]

There are two cpuidle governors ladder and menu. While the ladder
governor is always available, if CONFIG_CPU_IDLE is selected, the
menu governor additionally requires CONFIG_NO_HZ.

A particular C state can be disabled by writing to the sysfs file
/sys/devices/system/cpu/cpuN/cpuidle/stateN/disable, but this mechanism
is only implemented in the menu governor. Thus, in a system where
CONFIG_NO_HZ is not selected, the ladder governor becomes default and
always will walk through all sleep states - irrespective of whether the
C state was disabled via sysfs or not. The only way to select a specific
C state was to write the related latency to /dev/cpu_dma_latency and
keep the file open as long as this setting was required - not very
practical and not suitable for setting a single core in an SMP system.

With this patch, the ladder governor only will promote to the next
C state, if it has not been disabled, and it will demote, if the
current C state was disabled.

Note that the patch does not make the setting of the sysfs variable
"disable" coherent, i.e. if one is disabling a light state, then all
deeper states are disabled as well, but the "disable" variable does not
reflect it. Likewise, if one enables a deep state but a lighter state
still is disabled, then this has no effect. A related section has been
added to the documentation.

Signed-off-by: Carsten Emde <C.Emde@osadl.org>

---
 Documentation/cpuidle/sysfs.txt    |   10 +++++++++-
 drivers/cpuidle/governors/ladder.c |    4 +++-
 2 files changed, 12 insertions(+), 2 deletions(-)

Index: linux-3.4.4-rt14-rc2-64/Documentation/cpuidle/sysfs.txt
===================================================================
--- linux-3.4.4-rt14-rc2-64.orig/Documentation/cpuidle/sysfs.txt
+++ linux-3.4.4-rt14-rc2-64/Documentation/cpuidle/sysfs.txt
@@ -76,9 +76,17 @@ total 0
 
 
 * desc : Small description about the idle state (string)
-* disable : Option to disable this idle state (bool)
+* disable : Option to disable this idle state (bool) -> see note below
 * latency : Latency to exit out of this idle state (in microseconds)
 * name : Name of the idle state (string)
 * power : Power consumed while in this idle state (in milliwatts)
 * time : Total time spent in this idle state (in microseconds)
 * usage : Number of times this state was entered (count)
+
+Note:
+The behavior and the effect of the disable variable depends on the
+implementation of a particular governor. In the ladder governor, for
+example, it is not coherent, i.e. if one is disabling a light state,
+then all deeper states are disabled as well, but the disable variable
+does not reflect it. Likewise, if one enables a deep state but a lighter
+state still is disabled, then this has no effect.
Index: linux-3.4.4-rt14-rc2-64/drivers/cpuidle/governors/ladder.c
===================================================================
--- linux-3.4.4-rt14-rc2-64.orig/drivers/cpuidle/governors/ladder.c
+++ linux-3.4.4-rt14-rc2-64/drivers/cpuidle/governors/ladder.c
@@ -88,6 +88,7 @@ static int ladder_select_state(struct cp
 
 	/* consider promotion */
 	if (last_idx < drv->state_count - 1 &&
+	    !dev->states_usage[last_idx + 1].disable &&
 	    last_residency > last_state->threshold.promotion_time &&
 	    drv->states[last_idx + 1].exit_latency <= latency_req) {
 		last_state->stats.promotion_count++;
@@ -100,7 +101,8 @@ static int ladder_select_state(struct cp
 
 	/* consider demotion */
 	if (last_idx > CPUIDLE_DRIVER_STATE_START &&
-	    drv->states[last_idx].exit_latency > latency_req) {
+	    (dev->states_usage[last_idx].disable ||
+	    drv->states[last_idx].exit_latency > latency_req)) {
 		int i;
 
 		for (i = last_idx - 1; i > CPUIDLE_DRIVER_STATE_START; i--) {


  reply	other threads:[~2012-07-19 20:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-17 18:59 [PATCH 0/1] cpuidle: allow to disable C states of the ladder governor Carsten Emde
2012-07-17 18:59 ` [PATCH 1/1] Honor state disabling in the cpuidle " Carsten Emde
2012-07-18  6:36   ` Deepthi Dharwar
2012-07-18 11:02     ` Carsten Emde
2012-07-18 11:48       ` Deepthi Dharwar
2012-07-18 14:09         ` [PATCH 1/1 v2] Honor state disabling in the cpuidle ladder governor - documented Carsten Emde
2012-07-18 14:38         ` [PATCH 1/1 v3] Honor state disabling in the cpuidle ladder governor - with sanitizer Carsten Emde
2012-07-19 11:14           ` Deepthi Dharwar
2012-07-19 11:39             ` Carsten Emde
2012-07-19 18:42               ` Rafael J. Wysocki
2012-07-19 18:52               ` [PATCH 0/1 v2] cpuidle: allow to disable C states of the ladder governor Carsten Emde
2012-07-19 18:52                 ` [PATCH 1/1 v2] Honor state disabling in the cpuidle " Carsten Emde
2012-07-19 19:30                   ` Rafael J. Wysocki
2012-07-19 20:34                   ` [PATCH 0/1 v3] cpuidle: allow to disable C states of the " Carsten Emde
2012-07-19 20:34                     ` Carsten Emde [this message]
2012-07-19 21:48                       ` [PATCH 1/1 v3] Honor state disabling in the cpuidle " Rafael J. Wysocki
2012-07-19 22:22                         ` Carsten Emde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120719204338.905308004@osadl.org \
    --to=c.emde@osadl.org \
    --cc=deepthi@linux.vnet.ibm.com \
    --cc=khilman@ti.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.