lkml.org 
[lkml]   [2008]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 11/13] hrtimer: turn hrtimers into range timers
From
Date
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.
*/




\
 
 \ /
  Last update: 2008-09-02 15:49    [from the cache]
©2003-2011 Jasper Spaans