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

From: Ashwin Chaugule
Date: Mon Aug 31 2009 - 00:17:22 EST

Thomas Gleixner wrote:

That's not hard to fix by allowing the reprogramming to skip when the
new expiry time is the same as the old one.

I think that allowing the reprogram to skip is catching more cases
than the cached pointer. If the cached pointer is the one which gets
removed we might still reprogram with the same expiry value.
Um. Wouldn't the cached pointer point to the first (oldest) hrtimer in the series of timers with the same expires value ? Then it would be the last
hrtimer to be removed. I'm walking through the rbtree now to confirm this.

Can you please try the delta patch on top of the last one I sent ?
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.

If we knew in advance that this to-be-removed timer, was the oldest hrtimer
of the series, then we could force reprogram, such that we wake up only when the parent node timer is really going to expire. This may make a noticeable difference
in power for some devices.

Another question is, what happens when base->first of REALTIME and MONOTONIC both have the same expires ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at