Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period

On Tue, 12 Jan 2016, Daniel Lezcano wrote:

On 01/12/2016 04:12 PM, Thomas Gleixner wrote:

quoted

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.

Fair enough.