From patchwork Fri Aug 22 17:09:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frederic Weisbecker X-Patchwork-Id: 35860 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ig0-f197.google.com (mail-ig0-f197.google.com [209.85.213.197]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 9BC5220540 for ; Fri, 22 Aug 2014 17:10:03 +0000 (UTC) Received: by mail-ig0-f197.google.com with SMTP id r2sf49121204igi.8 for ; Fri, 22 Aug 2014 10:10:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=rI/odd4NGJAItiWeKo2AoMqOqKgUDd0s9zVYmfU2aCw=; b=P3qdtmAgeFbtGTE3N/pr+i8gpIXjgbVEfiOapwwtO3wAmKmLFimbULX1wkh0qEEDxw mbQS4ytv5PeH6oRt8rSNkTPdc+6yfLCYVv8xcxiXn49WpNmbGFWO8c+R3A4+LyHkHNOG 6coJ98bUzz2mFVIFM+RtkCNOAf4LNkeixRxLEOlBIvo38wUullGm/b8dT1ZbhqBGLLmy 2YqWwfIMrI94ubl2Noh8sCjpucwjx6e5sA9qKOsUVC4EJEmlf62U/pyqlcVmjjPpI71D 0xVFTlAI2jBzpIHiW+rzRuIjYv2KsoKgrCElU+/g5mRt91aAFxhrlLxDjRFBZPXF14Xn idcA== X-Gm-Message-State: ALoCoQnsxMiJP+Qxr4fWGKJhmOvFi/mRtz6/9jyYkLtrIThq/hwvbRfRz2fk+Mb8Nix3YJykrbji X-Received: by 10.42.35.10 with SMTP id o10mr7283863icd.6.1408727403163; Fri, 22 Aug 2014 10:10:03 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.95.21 with SMTP id h21ls1257893qge.52.gmail; Fri, 22 Aug 2014 10:10:02 -0700 (PDT) X-Received: by 10.52.170.69 with SMTP id ak5mr622408vdc.63.1408727402921; Fri, 22 Aug 2014 10:10:02 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [2607:f8b0:400c:c03::230]) by mx.google.com with ESMTPS id i6si14011713vdt.83.2014.08.22.10.10.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 10:10:02 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 2607:f8b0:400c:c03::230 as permitted sender) client-ip=2607:f8b0:400c:c03::230; Received: by mail-vc0-f176.google.com with SMTP id id10so12483800vcb.21 for ; Fri, 22 Aug 2014 10:10:02 -0700 (PDT) X-Received: by 10.52.89.211 with SMTP id bq19mr3526vdb.93.1408727402838; Fri, 22 Aug 2014 10:10:02 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.45.67 with SMTP id uj3csp32522vcb; Fri, 22 Aug 2014 10:10:02 -0700 (PDT) X-Received: by 10.66.222.199 with SMTP id qo7mr7829111pac.134.1408727401744; Fri, 22 Aug 2014 10:10:01 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pb7si1797342pdb.225.2014.08.22.10.10.00 for ; Fri, 22 Aug 2014 10:10:01 -0700 (PDT) Received-SPF: none (google.com: linux-kernel-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932633AbaHVRJp (ORCPT + 21 others); Fri, 22 Aug 2014 13:09:45 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:60852 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932531AbaHVRJl (ORCPT ); Fri, 22 Aug 2014 13:09:41 -0400 Received: by mail-wg0-f50.google.com with SMTP id n12so10518034wgh.21 for ; Fri, 22 Aug 2014 10:09:40 -0700 (PDT) X-Received: by 10.194.78.170 with SMTP id c10mr6636839wjx.22.1408727380598; Fri, 22 Aug 2014 10:09:40 -0700 (PDT) Received: from localhost.localdomain (4be54-h03-87-88-245-150.dsl.sta.abo.bbox.fr. [87.88.245.150]) by mx.google.com with ESMTPSA id lj18sm33116834wic.8.2014.08.22.10.09.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Aug 2014 10:09:39 -0700 (PDT) From: Frederic Weisbecker To: Ingo Molnar Cc: LKML , Viresh Kumar , Thomas Gleixner , Frederic Weisbecker Subject: [PATCH 1/2] nohz: Fix spurious periodic tick behaviour in low-res dynticks mode Date: Fri, 22 Aug 2014 19:09:32 +0200 Message-Id: <1408727373-8166-2-git-send-email-frederic@kernel.org> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1408727373-8166-1-git-send-email-frederic@kernel.org> References: <1408727373-8166-1-git-send-email-frederic@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Original-Sender: fweisbec@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 2607:f8b0:400c:c03::230 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org; dkim=neutral (body hash did not verify) header.i=@; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , From: Viresh Kumar When we reach the end of the tick handler, we unconditionally reschedule the next tick to the next jiffy. Then on irq exit, the nohz code overrides that setting if needed and defers the next tick as far away in the future as possible. Now in the best dynticks case, when we actually don't need any tick in the future (ie: expires == KTIME_MAX), low-res and high-res behave differently. What we want in this case is to cancel the next tick programmed by the previous one. That's what we do in high-res mode. OTOH we lack a low-res mode equivalent of hrtimer_cancel() so we simply don't do anything in this case and the next tick remains scheduled to jiffies + 1. As a result, in low-res mode, when the dynticks code determines that no tick is needed in the future, we can recursively get a spurious tick every jiffy because then the next tick is always reprogrammed from the tick handler and is never cancelled. And this can happen indefinetly until some subsystem actually needs a precise tick in the future and only then we eventually overwrite the previous tick handler setting to defer the next tick. We are fixing this by introducing the ONESHOT_STOPPED mode which will let us pause a clockevent when no further interrupt is needed. Meanwhile we can't expect all drivers to support this new mode. So lets reduce much of the symptoms by skipping the nohz-blind tick rescheduling from the tick-handler when the CPU is in dynticks mode. That tick rescheduling wrongly assumed periodicity and the low-res dynticks code can't cancel such decision. This breaks the recursive (and thus the worst) part of the problem. In the worst case now, we'll get only one extra tick due to uncancelled tick scheduled before we entered dynticks mode. This also removes a needless clockevent write on idle ticks. Since those clock write are usually considered to be slow, it's a general win. Reviewed-by: Preeti U Murthy Signed-off-by: Viresh Kumar Cc: Thomas Gleixner Signed-off-by: Frederic Weisbecker --- kernel/time/tick-sched.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 99aa6ee..153870a 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -968,6 +968,10 @@ static void tick_nohz_handler(struct clock_event_device *dev) tick_sched_do_timer(now); tick_sched_handle(ts, regs); + /* No need to reprogram if we are running tickless */ + if (unlikely(ts->tick_stopped)) + return; + while (tick_nohz_reprogram(ts, now)) { now = ktime_get(); tick_do_update_jiffies64(now);