This patch series is an early RFC to discuss the feasibility of
avoiding registering of idle states from each cpu.
The core change is to split the cpuidle_device structure into parts
that can be global and parts that has to remain per-cpu. The per-cpu
pieces are mostly generic statistics that can be independent of
current running driver.
* Simplify the cpuidle subsystem framework and have
registration/unregistration done by single cpu.
* Minimise the data structure that needs to be maintained for multiple
* Reference: https://lkml.org/lkml/2011/2/10/37
* Make the cpuidle framework simple for most use cases where C-States
are symmetric. In case there are asymmetric C-States detected,
fallback mechanism should be incorporated to maintain the system
functional https://lkml.org/lkml/2011/2/10/257 https://lkml.org/lkml/2011/2/10/37
* Non x86 archs that does not have asymmetric C-States like POWER, may
not need the fallback mechanism and hence the framework will be
simple for most use cases.
* Asymmetric C-States are part of x86 ACPI specification. Incorrect
handling may functionally affect the system
* Incorporating per-cpu masks for each state to allow/dis-allow global
states on subset of CPUs may result in an implementation that is
not better than current solution of having per-cpu states.
This patch series applies on top of the pm_idle cleanup patch https://lkml.org/lkml/2011/3/22/150 (cpuidle: Cleanup pm_idle and
include driver/cpuidle.c in-kernel)
This patch series is tested on x86 Nehalem system with multiple ACPI
This patch series has limitations of not handling multiple driver
registration and switching between drivers on all CPUs mainly due to
incomplete handling of per-cpu enable/disable and driver_data.
Please let us know your comments and suggest possible approaches to
Trinabh Gupta (2):
cpuidle: API changes in callers using new cpuidle_state_stats
cpuidle: Data structure changes for global cpuidle device
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/