Thanks for the update and sorry for the late reply. After long-term testing of
the patch, storm detection improved, it turns out that a similar problem can
occur if hrtimer_interrupt runs during clock_settime. In this case it seems the
offset can get updated and later read using hrtimer_update_base in
hrtimer_interrupt before softirq_expires_next gets updated. As soon as
softirq_expires_next gets updated by hrtimer_force_reprogram the storm ends. To
fix this I made the below changes.
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -529,8 +529,10 @@ static ktime_t __hrtimer_next_event_base(struct
hrtimer_cpu_base *cpu_base,
if (exclude)
continue;
- if (timer->is_soft)
+ if (timer->is_soft) {
cpu_base->softirq_next_timer = timer;
+ cpu_base->softirq_expires_next = expires;
+ }
else
cpu_base->next_timer = timer;
}
@@ -633,19 +635,6 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base,
int skip_equal)
*/
expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);
- if (cpu_base->next_timer && cpu_base->next_timer->is_soft) {
- /*
- * When the softirq is activated, hrtimer has to be
- * programmed with the first hard hrtimer because soft
- * timer interrupt could occur too late.
- */
- if (cpu_base->softirq_activated)
- expires_next = __hrtimer_get_next_event(cpu_base,
-
HRTIMER_ACTIVE_HARD);
- else
- cpu_base->softirq_expires_next = expires_next;
- }
-
if (skip_equal && expires_next == cpu_base->expires_next)
return;
--
This is similar to hrtimer_reprogram. I also removed the
cpu_base->softirq_activated case since as far as I can tell expires_next must
be hard if cpu_base->softirq_activated is true. I might be missing something as
I don't have whole picture of the hrtimer subsystem but at least no interrupt
storms are detected during clock_settime with latest changes.
Micke
