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.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
