Hi Uwe,
I'm happy to see you are able to reproduce the problem now.
This is a bit over my head as a newbie in the kernel, but I
will follow from the sideline ;-).
Thank you for taking care of the problem.
Best regards,
Bo
Uwe Kleine-König wrote:
Hello,
I'm able to reproduce this now. The problem is really that
hrtimer_interrupt() tries to program the next timer event which fails 4
times in a row, because the expiry time is already in the past when
tick_dev_program_event is called. This happens because there are so
much timers with small expiry times. (cyclictest -t40 on an UP machine)
Addionally the fourth interation was short (probably because then there
were no expired timers to check for) and so the try_time argument to
hrtimer_interrupt_hanging was small and so min_delta_ns was decreased
instead of increased.
I wonder why increasing min_delta_ns is supposed to fix something here.
Actually some pressure that results in hrtimer_interrupt_hanging being
called can always happen independently of min_delta_ns' value.
And moreover, is it sensible to change the value of
force_clock_reprogram? This makes the system harder to benchmark,
because to guarantee a certain latency now you have to check both
situations force_clock_reprogram==1 and force_clock_reprogram==0.
My suggestion is to do the following:
- fix hrtimer_interrupt_hanging not to decrease min_delta_ns
- in clockevents_program_event instead of
if (delta <= 0)
return -ETIME;
do
if (delta <= -dev->min_delta_ns)
return -ETIME;
I'm not sure though if -dev->min_delta_ns is the right value or if
that is a good idea at all.
Best regards
Uwe
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
