Re: [RFC 0/7] hrtimer: drop active hrtimer checks after adding it

2014-07-13 Thread Viresh Kumar
Hi Thomas, On 10 July 2014 07:04, Frederic Weisbecker wrote: > On Wed, Jul 09, 2014 at 11:30:41PM +0200, Thomas Gleixner wrote: >> On Wed, 9 Jul 2014, Viresh Kumar wrote: >> >> So your patch series drops active hrtimer checks after adding it, >> according to your subject line. >> >> Quite useeul

Re: [RFC 0/7] hrtimer: drop active hrtimer checks after adding it

2014-07-09 Thread Frederic Weisbecker
On Wed, Jul 09, 2014 at 11:30:41PM +0200, Thomas Gleixner wrote: > On Wed, 9 Jul 2014, Viresh Kumar wrote: > > So your patch series drops active hrtimer checks after adding it, > according to your subject line. > > Quite useeul to drop something after adding it, right? > > > hrtimer_start*() fam

Re: [RFC 0/7] hrtimer: drop active hrtimer checks after adding it

2014-07-09 Thread Thomas Gleixner
On Wed, 9 Jul 2014, Viresh Kumar wrote: So your patch series drops active hrtimer checks after adding it, according to your subject line. Quite useeul to drop something after adding it, right? > hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base. The > only special case is

[RFC 0/7] hrtimer: drop active hrtimer checks after adding it

2014-07-08 Thread Viresh Kumar
hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base. The only special case is when the hrtimer was in past. If it is getting enqueued to local CPUs's clock-base, we raise a softirq and exit, else we handle that on next interrupt on remote CPU. At several places in the kernel,