On Mon, Jan 20, 2014 at 05:00:20PM +0530, Viresh Kumar wrote: > On 16 January 2014 15:16, Thomas Gleixner <t...@linutronix.de> wrote: > > Just do the math. > > > > max reload value / timer freq = max time span > > Thanks. > > > So: > > > > 0x7fffffff / 24MHz = 89.478485 sec > > > > Nothing to do here except to get rid of the requirement to arm the > > timer at all. > > @Frederic: Any inputs on how to get rid of this timer here?
I fear you can't. If you schedule a timer in 4 seconds away and your clockdevice can only count up to 2 seconds, you can't help much the interrupt in the middle to cope with the overflow. So you need to act on the source of the timer: * identify what cause this timer * try to turn that feature off * if you can't then move the timer to the housekeeping CPU I'll have a look into the latter point to affine global timers to the housekeeping CPU. Per cpu timers need more inspection though. Either we rework them to be possibly handled by remote/housekeeping CPUs, or we let the associate feature to be turned off. All in one it's a case by case work. -- 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/
