Re: [RFC] [PATCH 1/1] hrtimers: Cache next hrtimer

From: Ashwin Chaugule
Date: Thu Sep 03 2009 - 13:48:28 EST

Thomas Gleixner wrote:

This looks very good ! Our results are almost similar now. However, I think
that with this new
patch we're still arming the timer needlessly at least once. This is the
case when we're trying to remove the first (oldest) hrtimer with
timer->expires = cpu->expires_next, but we forgo the reprogramming, when we
really shouldn't. At this point, with the current scheme of things, we will
needlessly wakeup and simply correct the expires_next value by
traversing up the rbtree, to the parent node.

That only happens, when that timer is the last one in both trees. Then
the resulting reprogramming value is KTIME_MAX and we skip the
reprogramming. That's easy to fix by removing the KTIME_MAX check.
Thinking more about this, I realized that the said case is already taken care of by hrtimer_interrupt. We have a while loop there which will traverse
to the parents on both trees and get the correct expires_next value.

In the case in remove_hrtimer, we actually don't want to reprogram the device,
because, the base->first node on the other tree with timer->expires = cpu->expires_next
hasn't expired yet.

Attached final patch here. Is this okay with you ?