[lkml]   [2018]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick
On Mon, Mar 05, 2018 at 04:36:20PM +0100, Thomas Ilsche wrote:
> I fear that might even create positive feedback loops on the
> heuristic, which will take into account the sleep durations for
> sched tick wakeups in sort of a self fulfilling prophecy:
> 1) The heuristic predicts to wake up in less than a full sched period,
> 2) The sched tick is kept enabled
> 3) The sched tick wakes up the system in less than a full sched period
> 4) Repeat

Right, I pointed out this same issue. We should ignore 'ticks' for the
purpose of measuring sleep duration.

That's slightly tricky to actually do though :/

> Question: Does disabling a timer on a cpu guarantee that this cpu will
> wake-up or is there a scenario where a timer is deleted or moved
> externally without the cpu having a chance to change it's idle state?

I think we let them sleep and don't modify any hardware timers,
resulting in them waking up at the predetermined time, not find anything
to do, recompute the next timer and go back to sleep.

Waking them up to reprogram the timer hardware is far more expensive.

 \ /
  Last update: 2018-03-05 17:51    [W:0.214 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site