cpuidle p-state dependency investigation
This blueprint has been moved to JIRA: https:/
In the cpuidle driver, the exit_latency value is used along with other data to determine which C-state the system will go into. But in reality, this exit_latency scales with the system clock frequency or p-state. This means the a constant exit_latency which is currently be used by most or all platforms is non-optimal. Using a constant value leads to either a worst case exit_latency being used which will sometimes unnecessarily prevent the system from entering the lowest level c-state, or if a non worst case constant exit_latency is used, it could cause a violation of the pm_qos limits for the CPU.
Further investigation will be done to determine the best implementation for a system that takes into account a dynamic exit_latency value (or any other dynamic values used by cpuidle).
Blueprint information
- Status:
- Complete
- Approver:
- Amit Kucheria
- Priority:
- Low
- Drafter:
- Rob
- Direction:
- Approved
- Assignee:
- Daniel Lezcano
- Definition:
- Superseded
- Series goal:
- Accepted for trunk
- Implementation:
-
Not started
- Milestone target:
-
backlog
- Started by
- Completed by
- Serge Broslavsky
Related branches
Related bugs
Sprints
Whiteboard
[amitk, 29/11/2012]: Daniel does this make sense to take on at this point? Or should we leave in backlog?
[daniel-lezcano, 25/03/2013]: the exit_latency has been provided by the cpuidle driver author. These measurements were done but I don't know in which context (w/o cpufreq, ondemand/
[daniel-lezcano, 12/04/2013] : one solution would be to measure the exit latency for different states at different frequency in the kernel at boot time and use these measured values to fill the exit_latency. The cpufreq notifiers will be used in the cpuidle framework to change the exit_latency dynamically.
[daniel-lezcano, 17/04/2013] : the question is how do you measure the exit latency ?
