Re: [PATCH 11/13] hrtimer: turn hrtimers into range timers

[Peter Zijlstra <peterz@infradead.org>]

On Tue, 2008-09-02 at 06:05 -0700, Arjan van de Ven wrote:
> On Tue, 02 Sep 2008 10:22:12 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Mon, 2008-09-01 at 16:08 -0700, Arjan van de Ven wrote:
> > 
> > > @@ -847,7 +847,8 @@ static void enqueue_hrtimer(struct hrtimer
> > > *timer,
> > >                  * We dont care about collisions. Nodes with
> > >                  * the same expiry time stay together.
> > >                  */
> > > -               if (timer->expires.tv64 < entry->expires.tv64) {
> > > +               if (hrtimer_get_expires_tv64(timer) <
> > > +                               hrtimer_get_expires_tv64(entry)) {
> > >                         link = &(*link)->rb_left;
> > >                 } else {
> > >                         link = &(*link)->rb_right;
> > 
> > On Mon, 2008-09-01 at 16:13 -0700, Arjan van de Ven wrote:
> > 
> > > +static inline void hrtimer_set_expires_range(struct hrtimer
> > > *timer, ktime_t time, ktime_t delta) +{
> > > +       timer->_softexpires = time;
> > > +       timer->_expires = ktime_add_safe(time, delta);
> > > +}
> > 
> > > @@ -241,10 +259,19 @@ static inline ktime_t
> > > hrtimer_get_expires(const struct hrtimer *timer) return
> > > timer->_expires; }
> > >  
> > > +static inline ktime_t hrtimer_get_softexpires(const struct hrtimer
> > > *timer) +{
> > > +	return timer->_expires;
> > > +}
> > 
> > Somehow the function is called softexpires, but returns the hard
> > expire time...
> 
> argh that's what you get if you split a patch into a series by hand ;-(
> 
> > > ktime_sub(hrtimer_get_expires(timer),
> > 
> > I might be missing something, but this code only looks at the leftmost
> > timer, and we're indexed on the hard expire time, which might be
> > rather far to the right of here.
> > 
> > This means that esp for those timers for which we can save most we're
> > least likely to do so because we'll plain not see them.
> 
> you're missing a little detail ;)
> 
> yes we start from left to right, and we stop once we find a timer that
> we can't fire anymore. The thing that you missed is that any timer
> after that (even if we could fire it now) will just be fired when the
> timer we stopped on fires.. so it'll still group them around those
> timers that are otherwise ungroupable.
> (it's not perfect by any means but it works ;-)

Gah, right. How about adding the following:

/*
 * The immediate goal is minimizing wakeups, not running
 * timers at the earliest interrupt after their soft expiration.
 * This allows us to avoid using a Priority Search Tree,
 * which can answer a stabbing querry for overlapping
 * intervals and instead use the simple BST we already have.
 * We don't add extra wakeups by delaying timers that are
 * right-of a not yet expired timer, because that timer will
 * have to trigger a wakeup anyway.
 */