From patchwork Tue Jul 3 02:16:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: john stultz X-Patchwork-Id: 9772 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 1A12F23E37 for ; Tue, 3 Jul 2012 02:17:45 +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 DE88FA1861D for ; Tue, 3 Jul 2012 02:17:44 +0000 (UTC) Received: by mail-yx0-f180.google.com with SMTP id q6so5197696yen.11 for ; Mon, 02 Jul 2012 19:17:44 -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-content-scanned:x-cbid:x-gm-message-state; bh=Mi1m0qAD4TzXIIEr2stQPt1Ma4JAjviNZIHvqWk6eQM=; b=GmYNXjUbWX3lucelQit7pHfZJ0Hymo+2Te9HjQ1BxfP3xRHWo9vBXU/7eFC1ih8Ywc ekkiu4g0DgqI3sHA3DexP05Jzq5pZsoDPO1+0ouSIuVGpO7+D4fCQJO3L73he3ovPOE8 d4yXjdh2flEgMCnyK8Tf5V2Vy9JjdgfTJUKcJucBweK388TCH0Cj4HvEqHhMbxT0eOqc edmkpIkIDJ7k2A1fe0OII9MZnQQWX8zZKPSm6Wuie4z8WT0VFTYygv7nOATAA0/33m2Z Bt3Q9ijPh4Rh4V+zGXH9UCh2Nd+WkiGcTfLQ2FlODoD29El2Eo5ZxWpcwP7Ad0MC+pPF 1Uig== Received: by 10.50.193.196 with SMTP id hq4mr6905771igc.57.1341281864533; Mon, 02 Jul 2012 19:17:44 -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 v20csp33993ibb; Mon, 2 Jul 2012 19:17:44 -0700 (PDT) Received: by 10.68.194.169 with SMTP id hx9mr3019258pbc.8.1341281863840; Mon, 02 Jul 2012 19:17:43 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com. [32.97.110.158]) by mx.google.com with ESMTPS id vh4si24487711pbc.323.2012.07.02.19.17.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 19:17:43 -0700 (PDT) Received-SPF: pass (google.com: domain of johnstul@us.ibm.com designates 32.97.110.158 as permitted sender) client-ip=32.97.110.158; Authentication-Results: mx.google.com; spf=pass (google.com: domain of johnstul@us.ibm.com designates 32.97.110.158 as permitted sender) smtp.mail=johnstul@us.ibm.com Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 Jul 2012 20:17:42 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 2 Jul 2012 20:17:42 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 41080C40002 for ; Tue, 3 Jul 2012 02:17:20 +0000 (WET) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q632Ghkv015766 for ; Mon, 2 Jul 2012 20:17:03 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q632GRlo003528 for ; Mon, 2 Jul 2012 20:16:27 -0600 Received: from kernel.stglabs.ibm.com (kernel.stglabs.ibm.com [9.114.214.19]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q632GMSC003254; Mon, 2 Jul 2012 20:16:25 -0600 From: John Stultz To: Linux Kernel Cc: John Stultz , Prarit Bhargava , stable@vger.kernel.org, Thomas Gleixner Subject: [PATCH 2/3] [RFC] time: Fix leapsecond triggered hrtimer/futex load spike issue Date: Mon, 2 Jul 2012 22:16:05 -0400 Message-Id: <1341281766-22722-3-git-send-email-johnstul@us.ibm.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1341281766-22722-1-git-send-email-johnstul@us.ibm.com> References: <1341281766-22722-1-git-send-email-johnstul@us.ibm.com> X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12070302-7408-0000-0000-0000066D0434 X-Gm-Message-State: ALoCoQkAiHQvoC+EnL6n45pKEwbcnHTZ8jrdMHQSLu7FxerZMLhYlgB5c+zVeBj4fq12LQFHGA9b 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 for this issue workaround is running: $ date -s "`date`" Credit: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix I this issue is due to the leapsecond being added without calling clock_was_set() to notify the hrtimer subsystem of the change. 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);