From patchwork Sun Jul 1 18:30:01 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: john stultz X-Patchwork-Id: 9720 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id 6049523E23 for ; Sun, 1 Jul 2012 18:30:20 +0000 (UTC) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.213.180]) by fiordland.canonical.com (Postfix) with ESMTP id 22883A183AB for ; Sun, 1 Jul 2012 18:30:20 +0000 (UTC) Received: by yenq6 with SMTP id q6so4008581yen.11 for ; Sun, 01 Jul 2012 11:30:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-forwarded-to:x-forwarded-for:delivered-to:received-spf:from:to:cc :subject:date:message-id:x-mailer:in-reply-to:references:x-cbid :x-gm-message-state; bh=66uNxKp5rRLdYjMM78H2BuEZ1SR+dbVnE5+eo8a6qFw=; b=XrWSMeIzPLOvB+bLqUekSQBWUal7AxZzSr5NEsCh2SX1OfrdfQbM9QQApZZYHelCWy N+OwQjj0qyo7sjRPO6qiWOfd9PICgZea8PhhETEMuwZEguJw1mtfKEQFp4ZlyEwCYpvR XM+bleMeknOV2LsMwfhDYbSG6kKwpqs4hKUU300EHp+R/7RecTbdE6azVWUHqmV0pPXb FRvVMlKA/Gt1p4EavYfP7imItytF68MtbW9Ug6+DFS1sYJfruN+X7okJqawthQ10EL6v djs9FDbL8GVlYFOIHh9bCXAseBy9O6A1hpZ4KqSX78YaT1kAviA5sjeYvwRRhxp9cloC V7FA== Received: by 10.42.155.73 with SMTP id t9mr4657889icw.48.1341167419150; Sun, 01 Jul 2012 11:30:19 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.231.24.148 with SMTP id v20csp13467ibb; Sun, 1 Jul 2012 11:30:18 -0700 (PDT) Received: by 10.43.92.67 with SMTP id bp3mr4644875icc.16.1341167418074; Sun, 01 Jul 2012 11:30:18 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com. [32.97.110.160]) by mx.google.com with ESMTPS id aj6si9567793igc.38.2012.07.01.11.30.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jul 2012 11:30:18 -0700 (PDT) Received-SPF: pass (google.com: domain of johnstul@us.ibm.com designates 32.97.110.160 as permitted sender) client-ip=32.97.110.160; Authentication-Results: mx.google.com; spf=pass (google.com: domain of johnstul@us.ibm.com designates 32.97.110.160 as permitted sender) smtp.mail=johnstul@us.ibm.com Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 1 Jul 2012 12:30:17 -0600 Received: from d03relay03.boulder.ibm.com (9.17.195.228) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 1 Jul 2012 12:30:14 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q61IUEAo239970 for ; Sun, 1 Jul 2012 12:30:14 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q61IUDYf023960 for ; Sun, 1 Jul 2012 12:30:13 -0600 Received: from kernel.stglabs.ibm.com (kernel.stglabs.ibm.com [9.114.214.19]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q61IUBgu023866; Sun, 1 Jul 2012 12:30:13 -0600 From: John Stultz To: Linux Kernel Cc: John Stultz , Prarit Bhargava , stable@vger.kernel.org, Thomas Gleixner Subject: [PATCH 2/2] [RFC] Fix leapsecond triggered hrtimer/futex load spike issue Date: Sun, 1 Jul 2012 14:30:01 -0400 Message-Id: <1341167401-31342-3-git-send-email-johnstul@us.ibm.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1341167401-31342-1-git-send-email-johnstul@us.ibm.com> References: <1341167401-31342-1-git-send-email-johnstul@us.ibm.com> x-cbid: 12070118-4242-0000-0000-0000022E32AD X-Gm-Message-State: ALoCoQm7nxtDsvbiCRFKv+y8HNwUfrZcKrpczKssESo8uIUsbRUt8hPUc7/bKqdELolNbdnYltNy 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 CC: stable@vger.kernel.org CC: Thomas Gleixner Reported-by: Jan Engelhardt Signed-off-by: John Stultz --- kernel/time/timekeeping.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 6f46a00..cc2991d 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -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);