Messages in this thread | | | Subject | Re: [PATCH 1/6] hrtimer: Provide clock_was_set_delayed() | From | Peter Zijlstra <> | Date | Wed, 11 Jul 2012 17:56:25 +0200 |
| |
On Wed, 2012-07-11 at 17:18 +0200, Thomas Gleixner wrote:
> Right. I think with the atomic update of the offset in the timer > interrupt we are on the safe side. The main problem of timers expiring > early forever is covered by this. > > Thinking more about it. > > If time goes backwards, then the IPI is pointless. The already armed > clockevent device will fire too early, hrtimer_interrupt will update > and just rearm it. That's one "spurious" event. > > So we only need it in the case of time going forward. > > Though with the leap second the maximum observable delay is 1 second > on a completely idle core. Surely nothing to worry about for an event > which happens rarely. So we could safely avoid the whole delayed > business and just do the timerfd notification, though I wonder if even > that is necessary in the leap second case. > > On NOHZ=n systems the IPI is pointless as well. The maximum lateness > will be 10ms for HZ=100. Nothing we should worry about. > > That leaves NOHZ enabled systems and there we might be clever and > avoid the IPIs to those cores which are not idle and let the tick > interrupt deal with it. And we can make the calls async and just let > them raise the hrtimer softirq on those cores, which will run the > hrtimer interrupt code and take care of everything. > > Thoughts?
static void nohz_hrtimer_softirq(void *unused) { raise_softirq(HRTIMER_SOFTIRQ); }
static void kick_nohz_cpus(void) { smp_call_function_many(nohz.idle_cpus_mask, nohz_hrtimer_softirq, NULL, 0); }
Same problem as before though, can't be sending IPIs while in hardirq context..
And you cannot do the same trick with a CFD as with the CSD, some CPUs might need it again while others are still pending.
| |