[BUG]: hrtimer overflow bug on 64-bit systems

[David Miller <davem@davemloft.net>]

I've been tracing this problem on sparc64 now that it uses hi-res
timers, and I finally figured it out.

The symptom is that ksoftirqd on most of the cpus of an idle SMP
system chew up around %10 of cpu time.

The raise_softirq_irqoff() is constantly being invoked via
tick_nohz_stop_sched_tick(), but why?

Tracing revealed that delta_ticks is enormous, which is correct
because no timers are pending on the cpu so we should schedule the
hrtimer as far into the future as possible.

tick_nohz_stop_sched_tick() then proceeds to start the hrtimer, and
then it checks hrtimer_active() but for some reason this is always
false.

Why?

The reason is that the expires calculation here:

		expires = ktime_add_ns(last_update, tick_period.tv64 *
				       delta_jiffies);

overflows on 64-bit systems.

On 32-bit systems, LONG_MAX is a 32-bit quantity so the largest
possible delta_jiffies don't cause an overflow in this multiply
(which is 64-bit).  (LONG_MAX determines how large a value
will be returned to indicate "infinity" from get_next_timer_interrupt(),
specifically it's the initialization of local variable 'expires'
in __next_timer_interrupt).

Because of this 'expires' is zero and of course that causes the
hrtimer to not get scheduled at all.

I'm surprised this problem is not seen with the x86_64 hrtimer patches
applied :-)

I'm not exactly sure how to best fix this, we could either make
__next_timer_interrupt use INT_MAX or we could make
tick_nohz_stop_sched_tick() realize and handle the overflow
properly.  Neither of those solutions are fully satisfactory in
my opinion :-)

FWIW, I've verified that using INT_MAX in __next_timer_interrupt()
makes the problem go away.

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