lkml.org 
[lkml]   [2016]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period
From
Date
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

\
 
 \ /
  Last update: 2016-01-12 17:41    [W:0.060 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site