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

[Ashwin Chaugule]

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 ?