It seems that the timer tick occurs with a PREEMPT_RT kernel even if configured
with NO_HZ_FULL. On a real-time system where some cores are configured with
isolcpu, the tick increases the execution jitter.
# tracer: nop
#
# entries-in-buffer/entries-written: 20219/20219 #P:8
#
# _-----=> irqs-off
# / _----=> need-resched
# |/ _-----=> need-resched_lazy
# || / _---=> hardirq/softirq
# ||| / _--=> preempt-depth
# |||| /_--=> preempt-lazy-depth
# ||||| _-=> migrate-disable
# ||||| / delay
# TASK-PID CPU# |||||| TIMESTAMP FUNCTION
# | | | |||||| | |
<idle>-0 [002] d..h2.. 41.314675:
hrtimer_expire_entry: hrtimer=ffff88013fc8f860
function=tick_sched_timer now=41136043338
<idle>-0 [002] d..h2.. 41.318675:
hrtimer_expire_entry: hrtimer=ffff88013fc8f860
function=tick_sched_timer now=41140043943
<idle>-0 [002] d..h2.. 41.322675:
hrtimer_expire_entry: hrtimer=ffff88013fc8f860
function=tick_sched_timer now=41144043138
I think the issue comes from commit 8aede461ab35 in kernel/time/timer.c:
u64 get_next_timer_interrupt(unsigned long basej, u64 basem)
{
[...]
#ifdef CONFIG_PREEMPT_RT_FULL
/*
* On PREEMPT_RT we cannot sleep here. As a result we can't take
* the base lock to check when the next timer is pending and so
* we assume the next jiffy.
*/
return basem + TICK_NSEC;
#endif
[...]
This commit is quite old, maybe a solution exists to the problem of base timer
locking. Would it be possible for instance to use RCU instead here to support
NO_HZ_FULL with a PREEMPT_RT kernel?
Thanks,
Francis
--
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
