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

[Thomas Gleixner]

On Thu, 27 Aug 2009, Ashwin Chaugule wrote:
> Thomas Gleixner wrote:
> > You forgot to describe the application scenario which triggers this.
> >    
> I didn't have anything specific running in userspace to trigger this. The
> sched_timer itself was causing most of the unnecessary reprogramming. I
> reckon, with more applications running, the timer_stats will show other timers
> (hrtimer_wakeup, it_real_fn etc.) that cause this effect too.

Hmm. That's related to NOHZ I guess. Ok, that's a serious issue and we
need to look at that.

> > So if I'm not totally on the wrong track, that's the meat of the
> > patch.
> >   
> Yup.
> > Any reason why we can't solve that problem with checking
> > cpu_base->expires_next against the timer which is deleted ? 
> > See the patently untested patch below.
> > 
> > Another question which arises is whether we should bother with the
> > reprogramming at all and just let the last programmed event happen
> > even when the corresponding timer has been removed.
> >   
> Hm. Interesting approach. See below.
> 
> So, you suggest checking the ktime of the hrtimer thats about to expire and
> compare it with expires_next ?

What's wrong with that ?

> I guess, another reason to go with caching the hrtimer is to avoid looping
> through HRTIMER_MAX_CLOCK_BASES, which may increase to more than 2 (?) for
> other architectures, and also all the code flow to arm the clock events
> device.
> With the caching approach, I also saw a 4% speedup in various application
> startups too.

Can you reevaluate against my patch please ?

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/