Message ID | 20230912104406.312185-4-frederic@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9ecd:0:b0:3f2:4152:657d with SMTP id t13csp378232vqx; Tue, 12 Sep 2023 05:44:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGLuPymtSlf9JvUBfRI89hRTSfIq7Dc5aB2/m2x3+Ma+cjqJ3KtM61tftnXoBROy5FPpXrd X-Received: by 2002:a17:903:496:b0:1bf:39d8:48f3 with SMTP id jj22-20020a170903049600b001bf39d848f3mr9409468plb.16.1694522693913; Tue, 12 Sep 2023 05:44:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694522693; cv=none; d=google.com; s=arc-20160816; b=ghyMhl/A69tz5B8b7ubaQs0fIIDuYpqVT+rs1C1nZtATy301+wmGszb4u9gcaHbEu3 b7EMZJHIUBhhAjtOUip6lD4+YOFKvg3LPRg3nWS9cJxnoFxSalNv/hOuWgiIFQemh3Ez KCdYBIewJRk+y08+B4uxW2qVYrXidrOPHiGaPPrFVTwTiiaaLdBbknD51t3JASokQtU7 XheBzofEfvehYxa+xjM0HC+ScRMoWi+RL4xi1/CNulbeLw9FbLbKb3kf8CDhCwDAwkAW cDvWgsiMRWazeM4xufG2y1lZWum3PxxXn5/nhInC0NBQjFDPCAlkoDaEi/q/c7XISXky /tqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=IySCpvlRDtWaBhfevoMuMq4DOFuV0e10hd277zPmJUs=; fh=KZsIGXP5HqVXbsRC9/8uC3fw6jb10xtWDpNz3O4AKxc=; b=YPlk3P52QPL/+2qSKEvuC+5EdraKOtxh/WuHaer5tLi+zYhSZgNppCNKCbWOhcmh8j WGDG2Y40Sc5MzhaLBf/sGbS7lLr1wAXYgMdEb991uXxjQqnPXlj7h/pqQ0cPcVqTT/fl f+r+jYTaLhPqENx3pDOlS16monl3H5geZZpwm5hmHZyEM5rIx0aMO0K5oRNEipcKGf/x xqmkYGqklO09B4U2+MN4zGqdH8F+UvH4oJeOC433vHl3BVcsxyExPpOfbTzYCVUkfbSZ QKVQo2rYlY8GPwxL+ikwvGBQBicS6mjXGWYLekFOCoYoHSNfMabo+RDSe8FLuYU6DQ48 EgJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tEbvCx9u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id d17-20020a170903209100b001bf0b29d935si7750435plc.34.2023.09.12.05.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 05:44:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tEbvCx9u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id D31DD81BD3FA; Tue, 12 Sep 2023 03:46:56 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234593AbjILKp3 (ORCPT <rfc822;pwkd43@gmail.com> + 37 others); Tue, 12 Sep 2023 06:45:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234453AbjILKov (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 12 Sep 2023 06:44:51 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CCC4172E for <linux-kernel@vger.kernel.org>; Tue, 12 Sep 2023 03:44:21 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52499C433C8; Tue, 12 Sep 2023 10:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1694515460; bh=8IMEGNQxJUVrw2F/l3GmN1Ldd+1Byg1w8yqybgZALh4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tEbvCx9uyF/x3U3frcNYdc0orFnxJFUZf6M65+NQ6QlTsM0zyiPtq33dJaI5zvgYq 3cA/hKUI7sBb8mYwLRFR2XMCSZ7+msxco0rRRkt9b8A2/xU1sr13E23dZC4zrut+xK HO0U+BjZqCW6XqlrCfWeLWcIWM0M1tsVMSpX/ziQumN3H7OGFjs++AR3BZLop5vWHG wI9Z/EeoOlPuw8p2fY95zQR0K0MATtZL3ca6JP9GqZ1+9RSR6lfpoSeUdeZD0PowRe vjbZz3TzGJZIPgeGezEFrQc9an1xqTqUf35Q5mhoz84fTZqWm07At91+Ksyh/JdwQf Il+4zUKLz0v1w== From: Frederic Weisbecker <frederic@kernel.org> To: LKML <linux-kernel@vger.kernel.org> Cc: Frederic Weisbecker <frederic@kernel.org>, Joel Fernandes <joel@joelfernandes.org>, Thomas Gleixner <tglx@linutronix.de>, vineethrp@gmail.com, Nicholas Piggin <npiggin@gmail.com> Subject: [PATCH 3/5] tick/nohz: Don't shutdown the lowres tick from itself Date: Tue, 12 Sep 2023 12:44:04 +0200 Message-Id: <20230912104406.312185-4-frederic@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230912104406.312185-1-frederic@kernel.org> References: <20230912104406.312185-1-frederic@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 12 Sep 2023 03:46:57 -0700 (PDT) X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1776835828097024247 X-GMAIL-MSGID: 1776835828097024247 |
Series |
tick/nohz: cleanups and fixes v2
|
|
Commit Message
Frederic Weisbecker
Sept. 12, 2023, 10:44 a.m. UTC
In lowres dynticks mode, just like in highres dynticks mode, when there
is no tick to program in the future, the tick eventually gets
deactivated either:
* From the idle loop if in idle mode.
* From the IRQ exit if in full dynticks mode.
Therefore there is no need to deactivate it from the tick itself. This
just just brings more overhead in the idle tick path for no reason.
Fixes: 62c1256d5447 ("timers/nohz: Switch to ONESHOT_STOPPED in the low-res handler when the tick is stopped")
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
kernel/time/tick-sched.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
Comments
On Tue, Sep 12, 2023 at 6:44 AM Frederic Weisbecker <frederic@kernel.org> wrote: > > In lowres dynticks mode, just like in highres dynticks mode, when there > is no tick to program in the future, the tick eventually gets > deactivated either: > > * From the idle loop if in idle mode. > * From the IRQ exit if in full dynticks mode. > > Therefore there is no need to deactivate it from the tick itself. This > just just brings more overhead in the idle tick path for no reason. > > Fixes: 62c1256d5447 ("timers/nohz: Switch to ONESHOT_STOPPED in the low-res handler when the tick is stopped") > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> If on some weird hardware, say ts->next_tick = KTIME_MAX but a spurious timer interrupt went off and tick_nohz_handler() did get called (yeah weird hypothetical situation), then in tick_nohz_stop_tick() we might early return from: /* Skip reprogram of event if its not changed */ if (ts->tick_stopped && (expires == ts->next_tick)) without no "eventual" reprogramming. Maybe we should also reprogram with KTIME_MAX in such a situation? Then we can get rid of it from tick_nohz_handler() for the common case as you are doing. So for weird hardware, with this patch we are not doing an extra tick_program_event(KTIME_MAX, 1); like Nick was doing. That makes me a tad bit nervous. Otherwise your patch looks correct to me (for hardware that tends not to misbehave). thanks, - Joel > --- > kernel/time/tick-sched.c | 24 +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 95a8d1d118a2..8e9a9dcf60d5 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -1403,18 +1403,16 @@ static void tick_nohz_lowres_handler(struct clock_event_device *dev) > tick_sched_do_timer(ts, now); > tick_sched_handle(ts, regs); > > - if (unlikely(ts->tick_stopped)) { > - /* > - * The clockevent device is not reprogrammed, so change the > - * clock event device to ONESHOT_STOPPED to avoid spurious > - * interrupts on devices which might not be truly one shot. > - */ > - tick_program_event(KTIME_MAX, 1); > - return; > + /* > + * In dynticks mode, tick reprogram is deferred: > + * - to the idle task if in dynticks-idle > + * - to IRQ exit if in full-dynticks. > + */ > + if (likely(!ts->tick_stopped)) { > + hrtimer_forward(&ts->sched_timer, now, TICK_NSEC); > + tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1); > } > > - hrtimer_forward(&ts->sched_timer, now, TICK_NSEC); > - tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1); > } > > static inline void tick_nohz_activate(struct tick_sched *ts, int mode) > @@ -1519,7 +1517,11 @@ static enum hrtimer_restart tick_nohz_highres_handler(struct hrtimer *timer) > else > ts->next_tick = 0; > > - /* No need to reprogram if we are in idle or full dynticks mode */ > + /* > + * In dynticks mode, tick reprogram is deferred: > + * - to the idle task if in dynticks-idle > + * - to IRQ exit if in full-dynticks. > + */ > if (unlikely(ts->tick_stopped)) > return HRTIMER_NORESTART; > > -- > 2.34.1 >
On Wed, Sep 13, 2023 at 09:17:21PM -0400, Joel Fernandes wrote: > On Tue, Sep 12, 2023 at 6:44 AM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > In lowres dynticks mode, just like in highres dynticks mode, when there > > is no tick to program in the future, the tick eventually gets > > deactivated either: > > > > * From the idle loop if in idle mode. > > * From the IRQ exit if in full dynticks mode. > > > > Therefore there is no need to deactivate it from the tick itself. This > > just just brings more overhead in the idle tick path for no reason. > > > > Fixes: 62c1256d5447 ("timers/nohz: Switch to ONESHOT_STOPPED in the low-res handler when the tick is stopped") > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > > If on some weird hardware, say ts->next_tick = KTIME_MAX but a > spurious timer interrupt went off and tick_nohz_handler() did get > called (yeah weird hypothetical situation), then in > tick_nohz_stop_tick() we might early return from: > > /* Skip reprogram of event if its not changed */ > if (ts->tick_stopped && (expires == ts->next_tick)) > > without no "eventual" reprogramming. > > Maybe we should also reprogram with KTIME_MAX in such a situation? > Then we can get rid of it from tick_nohz_handler() for the common case > as you are doing. > > So for weird hardware, with this patch we are not doing an extra > tick_program_event(KTIME_MAX, 1); like Nick was doing. That makes me a > tad bit nervous. So when a tick happens, ts->next_tick is reset to 0 (in tick_sched_handle()). This way if a timer interrupt fires too early, and that includes also timer interrupts when next_tick is KTIME_MAX, the timer is always reprogrammed upon the next idle loop iteration. So this shouldn't happen. Thanks.
On Thu, Sep 14, 2023 at 5:29 AM Frederic Weisbecker <frederic@kernel.org> wrote: > > On Wed, Sep 13, 2023 at 09:17:21PM -0400, Joel Fernandes wrote: > > On Tue, Sep 12, 2023 at 6:44 AM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > > > In lowres dynticks mode, just like in highres dynticks mode, when there > > > is no tick to program in the future, the tick eventually gets > > > deactivated either: > > > > > > * From the idle loop if in idle mode. > > > * From the IRQ exit if in full dynticks mode. > > > > > > Therefore there is no need to deactivate it from the tick itself. This > > > just just brings more overhead in the idle tick path for no reason. > > > > > > Fixes: 62c1256d5447 ("timers/nohz: Switch to ONESHOT_STOPPED in the low-res handler when the tick is stopped") > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > > > > If on some weird hardware, say ts->next_tick = KTIME_MAX but a > > spurious timer interrupt went off and tick_nohz_handler() did get > > called (yeah weird hypothetical situation), then in > > tick_nohz_stop_tick() we might early return from: > > > > /* Skip reprogram of event if its not changed */ > > if (ts->tick_stopped && (expires == ts->next_tick)) > > > > without no "eventual" reprogramming. > > > > Maybe we should also reprogram with KTIME_MAX in such a situation? > > Then we can get rid of it from tick_nohz_handler() for the common case > > as you are doing. > > > > So for weird hardware, with this patch we are not doing an extra > > tick_program_event(KTIME_MAX, 1); like Nick was doing. That makes me a > > tad bit nervous. > > So when a tick happens, ts->next_tick is reset to 0 (in tick_sched_handle()). > This way if a timer interrupt fires too early, and that includes also timer > interrupts when next_tick is KTIME_MAX, the timer is always reprogrammed upon > the next idle loop iteration. So this shouldn't happen. Ah you are right, I missed that. So then I am good with it: Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> thanks, - Joel
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 95a8d1d118a2..8e9a9dcf60d5 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -1403,18 +1403,16 @@ static void tick_nohz_lowres_handler(struct clock_event_device *dev) tick_sched_do_timer(ts, now); tick_sched_handle(ts, regs); - if (unlikely(ts->tick_stopped)) { - /* - * The clockevent device is not reprogrammed, so change the - * clock event device to ONESHOT_STOPPED to avoid spurious - * interrupts on devices which might not be truly one shot. - */ - tick_program_event(KTIME_MAX, 1); - return; + /* + * In dynticks mode, tick reprogram is deferred: + * - to the idle task if in dynticks-idle + * - to IRQ exit if in full-dynticks. + */ + if (likely(!ts->tick_stopped)) { + hrtimer_forward(&ts->sched_timer, now, TICK_NSEC); + tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1); } - hrtimer_forward(&ts->sched_timer, now, TICK_NSEC); - tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1); } static inline void tick_nohz_activate(struct tick_sched *ts, int mode) @@ -1519,7 +1517,11 @@ static enum hrtimer_restart tick_nohz_highres_handler(struct hrtimer *timer) else ts->next_tick = 0; - /* No need to reprogram if we are in idle or full dynticks mode */ + /* + * In dynticks mode, tick reprogram is deferred: + * - to the idle task if in dynticks-idle + * - to IRQ exit if in full-dynticks. + */ if (unlikely(ts->tick_stopped)) return HRTIMER_NORESTART;