30 Oct, 2013

1 commit

  • cpuidle_unregister_governor() and cpuidle_replace_governor() aren't
    used anymore and can be removed. They were used by cpufreq governors
    earlier, but since the governors can't be compiled as modules any
    more, these two functions aren't necessary.

    Suggested-by: Daniel Lezcano
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

23 Apr, 2013

1 commit

  • The usual scheme to initialize a cpuidle driver on a SMP is:

    cpuidle_register_driver(drv);
    for_each_possible_cpu(cpu) {
    device = &per_cpu(cpuidle_dev, cpu);
    cpuidle_register_device(device);
    }

    This code is duplicated in each cpuidle driver.

    On UP systems, it is done this way:

    cpuidle_register_driver(drv);
    device = &per_cpu(cpuidle_dev, cpu);
    cpuidle_register_device(device);

    On UP, the macro 'for_each_cpu' does one iteration:

    #define for_each_cpu(cpu, mask) \
    for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)

    Hence, the initialization loop is the same for UP than SMP.

    Beside, we saw different bugs / mis-initialization / return code unchecked in
    the different drivers, the code is duplicated including bugs. After fixing all
    these ones, it appears the initialization pattern is the same for everyone.

    Please note, some drivers are doing dev->state_count = drv->state_count. This is
    not necessary because it is done by the cpuidle_enable_device function in the
    cpuidle framework. This is true, until you have the same states for all your
    devices. Otherwise, the 'low level' API should be used instead with the specific
    initialization for the driver.

    Let's add a wrapper function doing this initialization with a cpumask parameter
    for the coupled idle states and use it for all the drivers.

    That will save a lot of LOC, consolidate the code, and the modifications in the
    future could be done in a single place. Another benefit is the consolidation of
    the cpuidle_device variable which is now in the cpuidle framework and no longer
    spread accross the different arch specific drivers.

    Signed-off-by: Daniel Lezcano
    Signed-off-by: Rafael J. Wysocki

    Daniel Lezcano
     

04 Sep, 2012

1 commit

  • 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
    Signed-off-by: Rafael J. Wysocki

    Carsten Emde
     

30 Mar, 2012

1 commit

  • Some C states of new CPU might be not good. One reason is BIOS might
    configure them incorrectly. To help developers root cause it quickly, the
    patch adds a new sysfs entry, so developers could disable specific C state
    manually.

    In addition, C state might have much impact on performance tuning, as it
    takes much time to enter/exit C states, which might delay interrupt
    processing. With the new debug option, developers could check if a deep C
    state could impact performance and how much impact it could cause.

    Also add this option in Documentation/cpuidle/sysfs.txt.

    [akpm@linux-foundation.org: check kstrtol return value]
    Signed-off-by: ShuoX Liu
    Reviewed-by: Yanmin Zhang
    Reviewed-and-Tested-by: Deepthi Dharwar
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    ShuoX Liu
     

14 Feb, 2008

1 commit