From patchwork Mon Jan 28 20:01:40 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 14315 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 A44E623E1A for ; Mon, 28 Jan 2013 20:01:56 +0000 (UTC) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by fiordland.canonical.com (Postfix) with ESMTP id 59638A18143 for ; Mon, 28 Jan 2013 20:01:56 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id cy12so1631841veb.28 for ; Mon, 28 Jan 2013 12:01:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-forwarded-to:x-forwarded-for:delivered-to:x-received :received-spf:x-received:from:to:cc:subject:date:message-id:x-mailer :x-gm-message-state; bh=CYBCuRfKvWGdvWS1lo4+DQ1rlhlPp1rlZ0v+RSgE6es=; b=BrCrD3iEtGgpqiWtBkPpEEohBxKiOt6nWCLovA4JzZ3pxGebMt+U+wE4AMcT2r1jQg BQkOYHRpJdWaQDBpWfe6GwyI7/Dx1BwpdZkBkWRDFRue5QbvpJtNXDzRMYF/i2z1zYYk UgaIM2LyzASXdAa22z5E7D8VTLQYovSabfWX45DFOlLGtr/c0y5cFmIcenubtckzmd0s SbKSrxlkFwL+JSdxJbDjzNI8NO4doeX921uXOKsVr/exoJRM2kDmn5rX5B8qbFVQPKHw Qkbu8Y4W0UrL1KJ7BcOdmKQbxPcbX3L15P99P5kJaNR/8YwxfvBYlN2aj7Vp8cbdHf1G g0Tg== X-Received: by 10.220.209.74 with SMTP id gf10mr16119996vcb.10.1359403315700; Mon, 28 Jan 2013 12:01:55 -0800 (PST) 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.58.145.101 with SMTP id st5csp101939veb; Mon, 28 Jan 2013 12:01:55 -0800 (PST) X-Received: by 10.66.81.199 with SMTP id c7mr38575202pay.39.1359403314579; Mon, 28 Jan 2013 12:01:54 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by mx.google.com with ESMTPS id qu6si10150107pbc.285.2013.01.28.12.01.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 12:01:54 -0800 (PST) Received-SPF: neutral (google.com: 209.85.210.48 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) client-ip=209.85.210.48; Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.210.48 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) smtp.mail=john.stultz@linaro.org Received: by mail-da0-f48.google.com with SMTP id k18so1413122dae.21 for ; Mon, 28 Jan 2013 12:01:53 -0800 (PST) X-Received: by 10.68.136.2 with SMTP id pw2mr14900793pbb.97.1359403313212; Mon, 28 Jan 2013 12:01:53 -0800 (PST) Received: from localhost.localdomain (c-24-21-54-107.hsd1.or.comcast.net. [24.21.54.107]) by mx.google.com with ESMTPS id ob9sm3167082pbb.73.2013.01.28.12.01.51 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 12:01:52 -0800 (PST) From: John Stultz To: stable@vger.kernel.org Cc: John Stultz , Willy Tarreau , Romain Francoise Subject: [PATCH] 2.6.32.y: timekeeping: Fix nohz issue with commit 61b76840ddee647c0c223365378c3f394355b7d7 Date: Mon, 28 Jan 2013 12:01:40 -0800 Message-Id: <1359403300-4149-1-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.7.10.4 X-Gm-Message-State: ALoCoQnXu5kiRPaBeW64sXSKo7mXSObVkC0TIIt+V8d1E/cCRAdL5aP4vbzR6o+9yAp+y1Z78ZQX Commit 61b76840ddee647c0c223365378c3f394355b7d7 ("time: Avoid making adjustments if we haven't accumulated anything") introduced a regression with nohz. Basically with kernels between 2.6.20-something to 2.6.32, we accumulate time in half second chunks, rather then every timer-tick. This was added because when NOHZ landed, if you were idle for a few seconds, you had to spin for every tick we skipped in the accumulation loop, which created some bad latencies. However, this required that we create the xtime_cache() which was still updated each tick, so that filesystem timestamps, etc continued to see time increment normally. Of course, the xtime_cache is updated at the bottom of update_wall_time(). So the early return on (offset < timekeeper.cycle_interval), added by the problematic commit causes the xtime_cache to not be updated. This can cause code using current_kernel_time() (like the mqueue code) or hrtimer_get_softirq_time(), which uses the non-updated xtime_cache, to see timers to fire with very coarse half-second granularity. Many thanks to Romain for describing the issue clearly, providing test case to reproduce it and helping with testing the solution. This change is for 2.6.32-stable ONLY! Cc: stable@vger.kernel.org Cc: Willy Tarreau Cc: Romain Francoise Reported-by: Romain Francoise Tested-by: Romain Francoise Signed-off-by: John Stultz --- kernel/time/timekeeping.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 3d35af3..f65a0fb 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -809,7 +809,7 @@ void update_wall_time(void) #endif /* Check if there's really nothing to do */ if (offset < timekeeper.cycle_interval) - return; + goto out; timekeeper.xtime_nsec = (s64)xtime.tv_nsec << timekeeper.shift; @@ -881,6 +881,7 @@ void update_wall_time(void) timekeeper.ntp_error += timekeeper.xtime_nsec << timekeeper.ntp_error_shift; +out: nsecs = clocksource_cyc2ns(offset, timekeeper.mult, timekeeper.shift); update_xtime_cache(nsecs);