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    [W:0.025 / U:30.752 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site