On Thursday, July 19, 2012, Carsten Emde wrote: > 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.e...@osadl.org>
Your patch doesn't seem to take this linux-next commit: http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=commit;h=dc7fd275ae60ef8edf952aff2a62462f5d892fd4 into account, does it? Rafael > --- > 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 && > + !drv->states[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) { > + (drv->states[last_idx].disable || > + drv->states[last_idx].exit_latency > latency_req)) { > int i; > > for (i = last_idx - 1; i > CPUIDLE_DRIVER_STATE_START; i--) { > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/