Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period
From: Daniel Lezcano
Date: Tue Jan 12 2016 - 11:04:45 EST
On 01/12/2016 04:12 PM, Thomas Gleixner wrote:
On Tue, 12 Jan 2016, Daniel Lezcano wrote:
On 01/12/2016 03:26 PM, Thomas Gleixner wrote:
You better implement the switching part in the cpuidle core first, i.e.
proper
callbacks when a governor is switched in/out. Then make use of this
switcheroo
right away. Doing it the other way round is just wrong.
The problem is this code is not another governor but a 'predictor' where the
scheduler will use the information to ask the cpuidle to go to a specific idle
state without going through the governor code, so into the governor's
callbacks. It is on top of cpuidle. The scheduler will become the governor.
The current straightforward code, does the switch in the cpu_idle_loop
idle_task's function:
[ ... ]
if (cpu_idle_force_poll || tick_check_broadcast_expired())
cpu_idle_poll();
else {
if (sched_idle_enabled()) {
int latency = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
s64 duration = sched_idle_next_wakeup();
sched_idle(duration, latency);
} else {
cpuidle_idle_call();
}
}
Due to the complexity of the code, this first step introduce a mechanism to
predict the next event and re-use it trivially in the idle task.
This looks really wrong. Why on earth don't you implement a proper governor
and just get rid of this extra hackery?
That is part of the ongoing work where we are integrating the different
PM subsystems with the scheduler in order have them collaborating
together as asked by Ingo [1].
The idea is to get rid of the governors and let the scheduler to tell
the Cpuidle framework : "I expect to sleep <x> nsec and I have a <y>
nsec latency requirement" as stated by Peter Zijlstra [2].
The code above could be not nice but I think it begins to do what is
expecting Peter. It is an embryonic code and in order to prevent too
much different topics for a single series, I posted the two first
patches which provide the next event API as the foundations for the next
changes. How we integrate the 'next event' is a question I wanted to
postpone in a different series of RFC patches.
-- Daniel
[1] http://lwn.net/Articles/552885/
[2] https://lkml.org/lkml/2013/11/11/353 (broken here is another archive [3]
[3] http://lkml.iu.edu/hypermail/linux/kernel/1311.1/01360.html
--
<http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog