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