Re: [PATCH 07/10] sched: Migrate sched to use new tick dependency mask model

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Aug 10, 2015 at 05:29:22PM +0200, Frederic Weisbecker wrote:

> Well, there could be a more proper way to do this without tying that
> to the scheduler tick. This could be some sort of
> hrtimer_cancel_soft() which more generally cancels a timer without
> cancelling the interrupt itself.

So when I looked at this last -- a long long time ago -- the whole
hrtimer rbtree took a significant amount of time. Hence the proposal
here to avoid all of it for this special timer.

> We might want to still keep track of
> that lost interrupt though in case of later clock reprogramming that
> fits the lost interrupt.  With a field like
> cpu_base->expires_interrupt. I thought about expires_soft and
> expires_hard but I think that terminology is already used :-)

Its easy enough to 'fix', but typically you'd reprogram a new sched tick
anyway, so its moot. Touching the hardware twice, once to cancel the
old, once to program the new, is double pain.

The only case where you really take that interrupt is when you cancel
and go idle I suppose, and we could special case that if the NOHZ code
doesn't already DTRT (by accident) etc..