From patchwork Thu Jul 31 16:45:55 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frederic Weisbecker X-Patchwork-Id: 34679 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yh0-f69.google.com (mail-yh0-f69.google.com [209.85.213.69]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id EB6FB20540 for ; Thu, 31 Jul 2014 16:46:43 +0000 (UTC) Received: by mail-yh0-f69.google.com with SMTP id v1sf10616709yhn.0 for ; Thu, 31 Jul 2014 09:46:43 -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=rmDEyUujujWJkiPIjq+NEOqYo0GsCpf+c3Bbe3gSEmA=; b=b5N2EnaZrrttUEelnoHKD+CB6l1R0HhrVUsHyw0BKtsSHMOHvRfTAq/vIFa2VQcHPW EheMEylWjI/C18NrhM53a5TKDcQZx63s0q0lDM31H+M63KNa7L6/XP9Qjm74OBflchVU eR9bKBT2S6ZeBbPuxwRdI8boSbSWkpdFORb7/w5cvJPwvrDEW3De9gSuuM1st/EgZzVL oJp3mvzZ3vBQ9ZWuvPrvzATqs2H1w1ynDR7Q0c1mRKrHD2vKtv8E2iwjkib4T1ppy+0J nJ/Ch6rI1vjtcTjsJzPUOIMy1r3dCmZfdPN9iJN+ERBKdukfkygCKTEsVHfCAmJKd/s2 JcZA== X-Gm-Message-State: ALoCoQnMu67r/uTBbBM6UylMxZ9HviC2VErKnQEBJoLtOK4q87dyVMBuFGjGze12KI9aBr6quXtL X-Received: by 10.224.130.10 with SMTP id q10mr4990983qas.5.1406825203739; Thu, 31 Jul 2014 09:46:43 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.80.36 with SMTP id b33ls1038783qgd.68.gmail; Thu, 31 Jul 2014 09:46:43 -0700 (PDT) X-Received: by 10.221.64.80 with SMTP id xh16mr14359225vcb.35.1406825203664; Thu, 31 Jul 2014 09:46:43 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [2607:f8b0:400c:c03::229]) by mx.google.com with ESMTPS id rd6si5008633vcb.39.2014.07.31.09.46.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 09:46:40 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 2607:f8b0:400c:c03::229 as permitted sender) client-ip=2607:f8b0:400c:c03::229; Received: by mail-vc0-f169.google.com with SMTP id le20so4579478vcb.14 for ; Thu, 31 Jul 2014 09:46:40 -0700 (PDT) X-Received: by 10.220.97.5 with SMTP id j5mr14363468vcn.16.1406825200843; Thu, 31 Jul 2014 09:46:40 -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.37.5 with SMTP id tc5csp33312vcb; Thu, 31 Jul 2014 09:46:40 -0700 (PDT) X-Received: by 10.68.192.106 with SMTP id hf10mr5899206pbc.30.1406825199954; Thu, 31 Jul 2014 09:46:39 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id os6si6599013pab.9.2014.07.31.09.46.39 for ; Thu, 31 Jul 2014 09:46:39 -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 S1753298AbaGaQqg (ORCPT + 19 others); Thu, 31 Jul 2014 12:46:36 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:57149 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753139AbaGaQqM (ORCPT ); Thu, 31 Jul 2014 12:46:12 -0400 Received: by mail-wi0-f182.google.com with SMTP id d1so4477409wiv.15 for ; Thu, 31 Jul 2014 09:46:10 -0700 (PDT) X-Received: by 10.180.206.38 with SMTP id ll6mr512550wic.40.1406825169263; Thu, 31 Jul 2014 09:46:09 -0700 (PDT) Received: from localhost.localdomain.com (8.20.196.77.rev.sfr.net. [77.196.20.8]) by mx.google.com with ESMTPSA id lk7sm14525230wjb.24.2014.07.31.09.46.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jul 2014 09:46:08 -0700 (PDT) From: Frederic Weisbecker To: Thomas Gleixner Cc: LKML , Viresh Kumar , Frederic Weisbecker Subject: [PATCH 1/2] nohz: Fix spurious periodic tick behaviour in low-res dynticks mode Date: Thu, 31 Jul 2014 18:45:55 +0200 Message-Id: <1406825156-11901-2-git-send-email-fweisbec@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1406825156-11901-1-git-send-email-fweisbec@gmail.com> References: <1406825156-11901-1-git-send-email-fweisbec@gmail.com> 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::229 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 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 6558b7a..b07ba8e 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -956,6 +956,10 @@ static void tick_nohz_handler(struct clock_event_device *dev) tick_sched_do_timer(now); tick_sched_handle(ts, regs); + /* Skip reprogramming next event 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);