]> www.infradead.org Git - users/jedix/linux-maple.git/commit
Fix leapsecond triggered hrtimer/futex load spike issue
authorJohn Stultz <john.stultz@linaro.org>
Mon, 2 Jul 2012 00:00:54 +0000 (20:00 -0400)
committerMaxim Uvarov <maxim.uvarov@oracle.com>
Thu, 5 Jul 2012 10:02:04 +0000 (03:02 -0700)
commit05b3801d5d008ec51a9b9afad9856ce15ee02265
tree3c2357701edf6351afa620073bc8a216d8c79116
parentf84af0ca7768cc12c300cfc42289706199a0c93c
Fix leapsecond triggered hrtimer/futex load spike issue

Backport for 3.0.36

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