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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/