From patchwork Mon Jun 23 08:09:37 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 32335 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 50C00203AC for ; Mon, 23 Jun 2014 08:09:50 +0000 (UTC) Received: by mail-ig0-f197.google.com with SMTP id r10sf10921054igi.4 for ; Mon, 23 Jun 2014 01:09:49 -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=Ck1DpuSpd8DsAQG01tP4rZeGOqZBBya/bqVKSKVzSlk=; b=YXfbwkifEzWh0zwBeJvp1cTZ6wOCvvqooQXHjHwoDT3ttrZ7Qv6TuxNPNln3sZBdLy jXep7U/M/1SDE9+4FCPdNyUrwwBiBj4gzkz4rIqJAigRAs7deGJYLkyCgi6+AmyqiDpQ kWHSfRKQqUnvvlW7JmsqpGf7l40w6qtO+b9g8d2q7igRi+y3W2GqFvMNJgq1OtvSWJMc JWOqPDpmJawpaMn2UvKEDH0pQejXIgNliLho0Z2GdOAAy40zhgJc3QaFAvu8/fXKHnxV FpDZbUhhaftYfZKODSNXySwa3zM8Q08dIq9x3UPx3zLDawXFe/7Fyv6pw4QcbVIf4iMR HCPA== X-Gm-Message-State: ALoCoQmCXUg0dUcvs7IHJW4y5SFZ6w5NzY5CqZbEPNgbrweZzM8AbgQl7/7SHtmanZMHYwPJCBkx X-Received: by 10.50.66.200 with SMTP id h8mr9051477igt.1.1403510989777; Mon, 23 Jun 2014 01:09:49 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.86.163 with SMTP id p32ls1772974qgd.42.gmail; Mon, 23 Jun 2014 01:09:49 -0700 (PDT) X-Received: by 10.220.167.2 with SMTP id o2mr17864376vcy.8.1403510989666; Mon, 23 Jun 2014 01:09:49 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx.google.com with ESMTPS id ut6si8582077veb.11.2014.06.23.01.09.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 01:09:49 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.174 as permitted sender) client-ip=209.85.220.174; Received: by mail-vc0-f174.google.com with SMTP id hy4so5520184vcb.5 for ; Mon, 23 Jun 2014 01:09:49 -0700 (PDT) X-Received: by 10.58.8.12 with SMTP id n12mr18210918vea.28.1403510989578; Mon, 23 Jun 2014 01:09:49 -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 tc5csp113172vcb; Mon, 23 Jun 2014 01:09:49 -0700 (PDT) X-Received: by 10.66.139.73 with SMTP id qw9mr26910279pab.123.1403510988719; Mon, 23 Jun 2014 01:09:48 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id aw13si14489545pac.24.2014.06.23.01.09.48; Mon, 23 Jun 2014 01:09:48 -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 S1752462AbaFWIJq (ORCPT + 9 others); Mon, 23 Jun 2014 04:09:46 -0400 Received: from mail-qc0-f178.google.com ([209.85.216.178]:62965 "EHLO mail-qc0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750722AbaFWIJo (ORCPT ); Mon, 23 Jun 2014 04:09:44 -0400 Received: by mail-qc0-f178.google.com with SMTP id c9so5711250qcz.37 for ; Mon, 23 Jun 2014 01:09:43 -0700 (PDT) X-Received: by 10.224.47.77 with SMTP id m13mr30769604qaf.69.1403510983460; Mon, 23 Jun 2014 01:09:43 -0700 (PDT) Received: from localhost (ec2-23-23-178-99.compute-1.amazonaws.com. [23.23.178.99]) by mx.google.com with ESMTPSA id k5sm28819930qao.30.2014.06.23.01.09.40 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Jun 2014 01:09:42 -0700 (PDT) From: Viresh Kumar To: tglx@linutronix.de Cc: linux-kernel@vger.kernel.org, Viresh Kumar , Frederic Weisbecker Subject: [PATCH V2 4/5] hrtimer: Kick lowres dynticks targets on timer enqueue Date: Mon, 23 Jun 2014 13:39:37 +0530 Message-Id: <3d7ea08ce008698e26bd39fe10f55949391073ab.1403507178.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.0.0.rc2 In-Reply-To: <1403393357-2070-5-git-send-email-fweisbec@gmail.com> References: <1403393357-2070-5-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-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.174 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org 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: , 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 --- Hi Thomas, Frederic is on vacations and so sending it directly. V1->V2: s/base/new_base as pointed out by Thomas. Pushed here as well: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git timers/missing-kick-v2 kernel/hrtimer.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index 0e32d4e..f900747 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(new_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