hrtimer_interrupt time sync issues across cores

Rajasekaran Chandrasekaran rajachan1982 at gmail.com
Thu Dec 14 02:01:57 EST 2017


Hi,


In our multi-core x86 based system that is running 3.4.19 version of
kernel, hrtimer_interrupt (called from apic_timer_interrupt) keeps looping
in hardirq for atleast 1.6 seconds.  We use tsc as our clock source. The
issue happens very rarely in our system and hard to reproduce.



Problem:

Inside hrtimer_interrupt function, basenow.tv64 in CPU-3 is 1.6 seconds
ahead of other CPU’s (we have 4 cores), whereas hrtimer->_softexpires.tv64
is in sync with remaining CPU’s. Due to this, the if condition inside
hrtimer_interrupt where we check if basenow.tv64 <
hrtimer_get_softexpires_tv64(timer) is not true for 1.6 seconds, which
cause the while loop inside hrtimer_interrupt to not exit. Below is the
ftrace captured during the problem.



<idle>-0     [002] d.h. 800364.533632: hrtimer_expire_entry:
hrtimer=ffff88017fd0c960 function=tick_sched_timer now=801616439840902

ksoftirqd/3-19    [003] dNh. 800364.539178: hrtimer_expire_entry:
hrtimer=ffff88017fd8c960 function=tick_sched_timer now=801618042768641

ksoftirqd/3-19    [003] dNh. 800364.539185: hrtimer_start:
hrtimer=ffff88017fd8c960 function=tick_sched_timer expires=801616446505014
softexpires=801616446505014



As we can see, the difference in now time between CPU-2 and CPU-3(where the
time jump is seen) is significant. Ftrace indicates that the now time has
drifted apart in CPU-3 by 1602 milliseconds, even though timestamp is apart
by only 6 milliseconds. Also since the hrtimer expiry time is in the past,
we end up spending lot of time in hardirq. From my understanding of the
code, , basenow.tv64  is computed in hrtimer_update_base()
->ktime_get_update_offsets() as timekeeper.xtime – offs_real. Both
timekeeper.xtime and offs_real are always updated under a lock.  So, I am
still unsure on how only one core is seeing the time incorrectly.


Any inputs will be greatly help.



Thanks,

Raj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171213/05fede11/attachment.html 


More information about the Kernelnewbies mailing list