@@ -963,6 +963,8 @@ static cycle_t logarithmic_accumulation(cycle_t offset, int shift)
leap = second_overflow(timekeeper.xtime.tv_sec);
timekeeper.xtime.tv_sec += leap;
timekeeper.wall_to_monotonic.tv_sec -= leap;
+ if (leap)
+ clock_was_set();
}
/* Accumulate raw time */
@@ -1079,6 +1081,8 @@ static void update_wall_time(void)
leap = second_overflow(timekeeper.xtime.tv_sec);
timekeeper.xtime.tv_sec += leap;
timekeeper.wall_to_monotonic.tv_sec -= leap;
+ if (leap)
+ clock_was_set();
}
timekeeping_update(false);
As widely reported on the internet, some Linux systems after the leapsecond was inserted are experiencing futex related load spikes (usually connected to MySQL, Firefox, Thunderbird, Java, etc). An apparent workaround for this issue is running: $ date -s "`date`" Credit: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix I believe this issue is due to the leapsecond being added without calling clock_was_set() to notify the hrtimer subsystem of the change. (Although I've not yet chased all the way down to the hrtimer code to validate exactly what's going on there). The workaround functions as it forces a clock_was_set() call from settimeofday(). This fix adds the required clock_was_set() calls to where we adjust for leapseconds. NOTE: This fix *depends* on the previous fix, which allows clock_was_set to be called from atomic context. Do not try to apply just this patch. CC: Prarit Bhargava <prarit@redhat.com> CC: stable@vger.kernel.org CC: Thomas Gleixner <tglx@linutronix.de> Reported-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: John Stultz <johnstul@us.ibm.com> --- kernel/time/timekeeping.c | 4 ++++ 1 file changed, 4 insertions(+)