On Thu, 7 Nov 2013, Frederic Weisbecker wrote:

On Thu, Nov 07, 2013 at 12:21:11PM +0100, Thomas Gleixner wrote:

quoted

Though it's not a full solution. It needs some thought versus the
softirq code of timers. Assume we have only one timer queued 1000
ticks into the future. So this change will cause the timer softirq not
to be called until that timer expires and then the timer softirq is
going to do 1000 loops until it catches up with jiffies. That's
anything but pretty ...

I see, so the problem is that we raise the timer softirq unconditionally
from the tick?

Right.
 

Ok we definetly don't want to keep that behaviour, even if softirqs are not
threaded, that's an overhead. So I'm looking at that loop in __run_timers()
and I guess you mean the "base->timer_jiffies" incrementation?

That's indeed not pretty. How do we handle exit from long dynticks
idle periods? Are we doing that loop until we catch up with the new
jiffies?

Right. I realized that right after I hit send :)
 

Then it relies on the timer cascade stuff which is very obscure code to me...

It's not that bad, really. I have an idea how to fix that. Needs some
rewriting though.

Thanks,

	tglx