Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp625889ybt; Mon, 6 Jul 2020 18:35:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyecGupDwS1aP2efesK11QoSrqFmv2Ax0C/+PJ2s1iX83UgdBIkHdCuYPfJo8dPOveZNkkv X-Received: by 2002:a50:8143:: with SMTP id 61mr59834935edc.202.1594085733882; Mon, 06 Jul 2020 18:35:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594085733; cv=none; d=google.com; s=arc-20160816; b=sRPwtRYbtQfmuRRpyOxbUS8GAukEuPESG6aCzyWTJPznEx0+WOXnRA1tPMtOIom7ca HMiJil8Czs+zImSOdeIA5SR6dsRmtmDqKcJ8XBohZ/uh2zNlfHZ4SzuCfbOtrX1icNg5 ARgykBKNDEO/K6brfGbFuR0FHqZeSzobipGeI4Fj6zQ8OX7w1HfPfL1rVbzdzkES1MPH AYk4KFUCCcIvjCubhs6tiw25ztB1xTiv/jyReQL1/DpUWCRzUaoyG5TVVK+D9qIh2CZF 8Ine4FEov86aZgTgP7dl5MGQsERMLJA03HQX53h+hSGlbnEFoSPs6vjxdVND4z252fpB Nc8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=U7pXPIQpYyQT8jcgePn5y1Z2ttEnYWxE3Um2E6k75iU=; b=yjHWxnrTbN/iiUnblxyor4lVnFXsYtt/VaNi4FJnN2Gp0mk8yoHo0mIhPtno9rCoOf cHSx8kDxW4W4FTsvpi7V59eX0ht9Ij+IM5LrUmM0cu4kYUCKQ/lJhvSZ6+7zR4WHw83n iFGq4Om3XrNqXKn/+dUB3HjPMzL9SxwK04u1qzUvFMUu6PGzKS8l0SGCL1riVKnkgi7p flZSdp0x/VSZOW3Sii0k2tVUYbXEEPHkgWLxTJewATtABE80mOf8+KKOP851uUMJv+ps SXM5H8hpszbNtRqZJHikkz6+2IjJpz/umvzGjxFzrYRYyHjwOIpz03xMFADmAPIGLJ8g /TIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=thqqfQe1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w19si14123788eju.41.2020.07.06.18.35.10; Mon, 06 Jul 2020 18:35:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=thqqfQe1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728086AbgGGBd0 (ORCPT + 99 others); Mon, 6 Jul 2020 21:33:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:38742 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727989AbgGGBdR (ORCPT ); Mon, 6 Jul 2020 21:33:17 -0400 Received: from lenoir.home (lfbn-ncy-1-317-216.w83-196.abo.wanadoo.fr [83.196.152.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6072820708; Tue, 7 Jul 2020 01:33:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594085595; bh=jlK/Hyqs9cc0jFdUpMVZ/tN8XrVyN4678rXR90mQi7g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=thqqfQe1/I9DEmjXACbus7OJ8iPFQwSh/NBrJsGjBG307NHDaPENsC0MG7nnxc8b9 9K/095iAC2q/BfCou5iIGhoSNkhC5Tf1P0/7HjzlSTSqVPzC3L9Gakk2aQ01EOf/p8 BckFOm8K2Mu2fges6Sdgh4sAg3YFoyD5cCoejz8k= From: Frederic Weisbecker To: Thomas Gleixner Cc: LKML , Frederic Weisbecker , Anna-Maria Gleixner , Peter Zijlstra , Juri Lelli Subject: [PATCH 6/9] timer: Expand clk forward logic beyond nohz Date: Tue, 7 Jul 2020 03:32:50 +0200 Message-Id: <20200707013253.26770-7-frederic@kernel.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200707013253.26770-1-frederic@kernel.org> References: <20200707013253.26770-1-frederic@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As for next_expiry, we want to expand base->clk catch up logic beyond nohz in order to avoid triggering useless softirqs. If we want to fire softirqs only to expire pending timers, periodic base->clk increments must be skippable for random amounts of time. Therefore we must prepare to catch-up with missing updates whenever we need an up-to-date base clock. Signed-off-by: Frederic Weisbecker Cc: Peter Zijlstra Cc: Anna-Maria Gleixner Cc: Juri Lelli --- kernel/time/timer.c | 26 ++++---------------------- 1 file changed, 4 insertions(+), 22 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 501d36ef0b75..ffa2c956d968 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -885,19 +885,12 @@ get_target_base(struct timer_base *base, unsigned tflags) static inline void forward_timer_base(struct timer_base *base) { -#ifdef CONFIG_NO_HZ_COMMON unsigned long jnow; - /* - * We only forward the base when we are idle or have just come out of - * idle (must_forward_clk logic), and have a delta between base clock - * and jiffies. In the common case, run_timers will take care of it. - */ - if (likely(!base->must_forward_clk)) + if (!base->must_forward_clk) return; jnow = READ_ONCE(jiffies); - base->must_forward_clk = base->is_idle; if ((long)(jnow - base->clk) < 2) return; @@ -912,7 +905,6 @@ static inline void forward_timer_base(struct timer_base *base) return; base->clk = base->next_expiry; } -#endif } @@ -1666,10 +1658,8 @@ u64 get_next_timer_interrupt(unsigned long basej, u64 basem) * logic is only maintained for the BASE_STD base, deferrable * timers may still see large granularity skew (by design). */ - if ((expires - basem) > TICK_NSEC) { - base->must_forward_clk = true; + if ((expires - basem) > TICK_NSEC) base->is_idle = true; - } } raw_spin_unlock(&base->lock); @@ -1768,16 +1758,7 @@ static inline void __run_timers(struct timer_base *base) /* * timer_base::must_forward_clk must be cleared before running * timers so that any timer functions that call mod_timer() will - * not try to forward the base. Idle tracking / clock forwarding - * logic is only used with BASE_STD timers. - * - * The must_forward_clk flag is cleared unconditionally also for - * the deferrable base. The deferrable base is not affected by idle - * tracking and never forwarded, so clearing the flag is a NOOP. - * - * The fact that the deferrable base is never forwarded can cause - * large variations in granularity for deferrable timers, but they - * can be deferred for long periods due to idle anyway. + * not try to forward the base. */ base->must_forward_clk = false; @@ -1790,6 +1771,7 @@ static inline void __run_timers(struct timer_base *base) while (levels--) expire_timers(base, heads + levels); } + base->must_forward_clk = true; raw_spin_unlock_irq(&base->lock); timer_base_unlock_expiry(base); } -- 2.26.2