From patchwork Sat Jun 21 23:29:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frederic Weisbecker X-Patchwork-Id: 32310 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-vc0-f200.google.com (mail-vc0-f200.google.com [209.85.220.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 89E51203F4 for ; Sat, 21 Jun 2014 23:30:40 +0000 (UTC) Received: by mail-vc0-f200.google.com with SMTP id id10sf16909346vcb.7 for ; Sat, 21 Jun 2014 16:30:40 -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=HnVTD7iIKRbSIPK++c47H2CYOyckgidIIVX8RYea82c=; b=PR3Oo8tT5k48bpQ0E2r93TeZBcDIa3Sqsm5lQPg2/zJMa9wIukSSl9Qs4yCS2/lgHk 2dWEo7hIQXC9IGKlxyHoc0Sn4CocohUbiMGr3+fkHPCdVDlifsY2v31KvNAMAYCzMqqe fbr7KlpOHzOdueoQE8xHLAshMjo+MBv/mdJL+WMgRj/iaXooEQq4QK9b6Tuilahjnf8A MFc/2N9IyL6QkHL+H9Voz8Xamr1G0mipgXSUFa6/kw5j66LATPqwvzfM9CtrSdbGiWGP +HSSM2eC6yJejc7Lu+t2hDa3JmbNyZBtHydt6CIk9b2Lztqiek08p76l9sqkSmJWly9F thrQ== X-Gm-Message-State: ALoCoQkxlqzKs/H6IdlkIqFV4eUrGxS9YaTIgMm7SiPkRKYXJREbNnAvHFicJHKK+Bv3M634bnuL X-Received: by 10.236.136.231 with SMTP id w67mr4878345yhi.37.1403393440344; Sat, 21 Jun 2014 16:30:40 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.102.78 with SMTP id v72ls1469719qge.0.gmail; Sat, 21 Jun 2014 16:30:40 -0700 (PDT) X-Received: by 10.221.29.137 with SMTP id ry9mr10654130vcb.6.1403393440265; Sat, 21 Jun 2014 16:30:40 -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 li19si6557785vdb.62.2014.06.21.16.30.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Jun 2014 16:30: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 la4so4744977vcb.28 for ; Sat, 21 Jun 2014 16:30:40 -0700 (PDT) X-Received: by 10.221.5.1 with SMTP id oe1mr10706115vcb.10.1403393440154; Sat, 21 Jun 2014 16:30: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 tc5csp44342vcb; Sat, 21 Jun 2014 16:30:39 -0700 (PDT) X-Received: by 10.66.137.109 with SMTP id qh13mr16706427pab.39.1403393439452; Sat, 21 Jun 2014 16:30:39 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ea5si15653498pad.63.2014.06.21.16.30.38; Sat, 21 Jun 2014 16:30:38 -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 S1753012AbaFUX3n (ORCPT + 13 others); Sat, 21 Jun 2014 19:29:43 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:42745 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbaFUX32 (ORCPT ); Sat, 21 Jun 2014 19:29:28 -0400 Received: by mail-we0-f174.google.com with SMTP id u57so5248417wes.19 for ; Sat, 21 Jun 2014 16:29:27 -0700 (PDT) X-Received: by 10.181.13.80 with SMTP id ew16mr14345171wid.51.1403393367159; Sat, 21 Jun 2014 16:29:27 -0700 (PDT) Received: from localhost.localdomain (8.20.196.77.rev.sfr.net. [77.196.20.8]) by mx.google.com with ESMTPSA id sg1sm41744wic.4.2014.06.21.16.29.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jun 2014 16:29:26 -0700 (PDT) From: Frederic Weisbecker To: Thomas Gleixner Cc: LKML , Viresh Kumar , Frederic Weisbecker Subject: [PATCH 4/5] hrtimer: Kick lowres dynticks targets on timer enqueue Date: Sun, 22 Jun 2014 01:29:16 +0200 Message-Id: <1403393357-2070-5-git-send-email-fweisbec@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1403393357-2070-1-git-send-email-fweisbec@gmail.com> References: <1403393357-2070-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 In lowres mode, hrtimers are serviced by the tick instead of a clock event. It works well as long as the tick stays periodic but we must also make sure that the hrtimers are serviced in dynticks mode targets, pretty much like timer list timers do. Note that all dynticks modes are concerned: get_nohz_timer_target() tries not to return remote idle CPUs but there is nothing to prevent the elected target from entering dynticks idle mode until we lock its base. It's also prefectly legal to enqueue hrtimers on full dynticks CPU. So there are two requirements to correctly handle dynticks: 1) On target's tick stop time, we must not delay the next tick further the next hrtimer. 2) On hrtimer queue time. If the tick of the target is stopped, we must wake up that CPU such that it sees the new hrtimer and recalculate the next tick accordingly. The point 1 is well handled currently through get_nohz_timer_interrupt() and cmp_next_hrtimer_event(). But the point 2 isn't handled at all. Fixing this is easy though as we have the necessary API ready for that. All we need is to call wake_up_nohz_cpu() on a target when a newly enqueued hrtimer requires tick rescheduling, like timer list timer do. Signed-off-by: Viresh Kumar Signed-off-by: Frederic Weisbecker --- kernel/hrtimer.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index 0e32d4e..5f30917 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -1013,14 +1013,25 @@ int __hrtimer_start_range_ns(struct hrtimer *timer, ktime_t tim, leftmost = enqueue_hrtimer(timer, new_base); - /* - * Only allow reprogramming if the new base is on this CPU. - * (it might still be on another CPU if the timer was pending) - * - * XXX send_remote_softirq() ? - */ - if (leftmost && new_base->cpu_base == &__get_cpu_var(hrtimer_bases) - && hrtimer_enqueue_reprogram(timer, new_base)) { + if (!leftmost) { + unlock_hrtimer_base(timer, &flags); + return ret; + } + + if (!hrtimer_is_hres_active(timer)) { + /* + * Kick to reschedule the next tick to handle the new timer + * on dynticks target. + */ + wake_up_nohz_cpu(base->cpu_base->cpu); + } else if (new_base->cpu_base == &__get_cpu_var(hrtimer_bases) && + hrtimer_enqueue_reprogram(timer, new_base)) { + /* + * Only allow reprogramming if the new base is on this CPU. + * (it might still be on another CPU if the timer was pending) + * + * XXX send_remote_softirq() ? + */ if (wakeup) { /* * We need to drop cpu_base->lock to avoid a