Displaying 3 results from an estimated 3 matches for "irq_timings_next_ev".
2017 Nov 16
2
[PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On 16/11/2017 10:12, Quan Xu wrote:
>
>
> On 2017-11-16 06:03, Thomas Gleixner wrote:
>> On Wed, 15 Nov 2017, Peter Zijlstra wrote:
>>
>>> On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:
>>>> From: Yang Zhang <yang.zhang.wz at gmail.com>
>>>>
>>>> Implement a generic idle poll which resembles the functionality
2017 Nov 16
2
[PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On 16/11/2017 10:12, Quan Xu wrote:
>
>
> On 2017-11-16 06:03, Thomas Gleixner wrote:
>> On Wed, 15 Nov 2017, Peter Zijlstra wrote:
>>
>>> On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:
>>>> From: Yang Zhang <yang.zhang.wz at gmail.com>
>>>>
>>>> Implement a generic idle poll which resembles the functionality
2017 Nov 20
0
[PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
...sion.
>>
>> interesting. I have tested with IRQ_TIMINGS related code, which seems
>> not working so far.
> I don't know how you tested it, can you elaborate what you meant by
> "seems not working so far" ?
Daniel, I tried to enable IRQ_TIMINGS* manually. used
irq_timings_next_event()
to return estimation of the earliest interrupt. However I got a constant.
> There are still some work to do to be more efficient. The prediction
> based on the irq timings is all right if the interrupts have a simple
> periodicity. But as soon as there is a pattern, the current code...