Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp403264rdg; Thu, 12 Oct 2023 08:53:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGWh0OY2q+MsOud1UJj7uDL1VgEXJIqRMgfVZOjWoEMOqlIBd+JShuzbtRIP1LvfRlawMvK X-Received: by 2002:a05:6358:2786:b0:142:f1d5:ef89 with SMTP id l6-20020a056358278600b00142f1d5ef89mr26712672rwb.5.1697125993085; Thu, 12 Oct 2023 08:53:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697125993; cv=none; d=google.com; s=arc-20160816; b=NmmzUxr8hDBs3ML5ZxEX6UyHBxSxjwvsqgiFFfvL6zHvFPeEH6O8DvdG0/FN7dhFKR nRGEma4Ik8XfX/OtfYE7RkZl5m3z0QtZM7syoNMiZacxAtEZDVLB/HdnaOG0xKX6U+6n LGVxGiHtOK8TSjEgF4PavdI8/Ljk/Crpf+iuOKdCCURk5NXtGr544l2rq9O1wQSGbd5P /7PVMDT388mNAuiK0XidunPRdylcLkBUD2ClKJsvt7Ib9jfcMz1nGA7hVS1FSuXZYgrs MBkRHWed10TaWbOiWnpWD5cxrNr/Orbe8Bvy5PVTNY4Mso10CGTAamLqKqcUM+GTb7kP 4WKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=TYFaAgumGo+PpGv14/dq7enWc4QGYBZeeWtA85R9ZXo=; fh=rlwn4pxNjzZxzAe0OFpEm5XldgGOhioyoE/W5GSrSmE=; b=tC4MEqxFDgYGg4swW18ZbJpGGPogPegk9Y/kdAWtL68qKYz/jmMfqCCafQjq+vE90o kbKegs9v6ULqY/gT9e6Wbcr7m97cLTicNwV7zCawFNmNVFQJidglVX6jl9aLlCf5j1py /a5kKKmZ2gflLQSpxh4NFqksbfUNZlrnIXR5mwIXEhORV1yrV7DTxnQ5OvWQlnOx35u/ YmPFV9/zAiKdEy4B67OkBOutbDe9UvLjyeHjNzUHNTgeF3p8gIDmcoRqp85Q0AVuhQgL HVT0z1vqzqLAwcXCEWyB6VAhxK4wU0kwZfFHa+dfyp1BGTx8KXaKHQ4undpdjSZ0gZ0/ Ytaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lBp+BUbY; 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 Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id cl4-20020a056a0032c400b0068a5877bfaesi14786422pfb.382.2023.10.12.08.53.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 08:53:13 -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=lBp+BUbY; 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 6DECE8043068; Thu, 12 Oct 2023 08:53:10 -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 S1347251AbjJLPw6 (ORCPT + 99 others); Thu, 12 Oct 2023 11:52:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235697AbjJLPwz (ORCPT ); Thu, 12 Oct 2023 11:52:55 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1AF2C0 for ; Thu, 12 Oct 2023 08:52:53 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12284C433C8; Thu, 12 Oct 2023 15:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697125973; bh=59K4iGekkWwDLDUC5rLrFmi/slgimt2MTbMdwt9WSi0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lBp+BUbYpd/YaPoVSB/uUEflFKoMssInos8CrNILJVURJ4ZgGDnVwsgmnmCnBJE8a UpY3ZJbn/9WIh/Qdd6MBb7YN8fiGXVgFeJmzF6tt+4JBHkGWWgAnHROxzoR7Ni0mI4 G4wCKiPE7JkPR0LLeSvqqd9/eISSTA7eVlmhzI3oYVhButFBTpm2PlOXFYx5SBGmtt 1lJ1N3Yx7dF3LYpnckBUsvSCT7mcRBCku3x5k6uYFU+fuws/XxqOYb9s+RJa0cBePV 1T50h4+WabYVBRO7wJ+3Yd9Vrbk8cQ1pOiTaVCG1DELdG7Ir1hE2PwRiNOmOiVP4a6 OB2y4wbrnW97Q== Date: Thu, 12 Oct 2023 17:52:49 +0200 From: Frederic Weisbecker To: Anna-Maria Behnsen Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , John Stultz , Thomas Gleixner , Eric Dumazet , "Rafael J . Wysocki" , Arjan van de Ven , "Paul E . McKenney" , Rik van Riel , Steven Rostedt , Sebastian Siewior , Giovanni Gherdovich , Lukasz Luba , "Gautham R . Shenoy" , Srinivas Pandruvada , K Prateek Nayak Subject: Re: [PATCH v8 10/25] timers: Move marking timer bases idle into tick_nohz_stop_tick() Message-ID: References: <20231004123454.15691-1-anna-maria@linutronix.de> <20231004123454.15691-11-anna-maria@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231004123454.15691-11-anna-maria@linutronix.de> 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 Precedence: bulk List-ID: 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]); Thu, 12 Oct 2023 08:53:10 -0700 (PDT) Le Wed, Oct 04, 2023 at 02:34:39PM +0200, Anna-Maria Behnsen a ?crit : > static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) > { > struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev); > + unsigned long basejiff = ts->last_jiffies; > u64 basemono = ts->timer_expires_base; > - u64 expires = ts->timer_expires; > + bool timer_idle = ts->tick_stopped; > + u64 expires; > > /* Make sure we won't be trying to stop it twice in a row. */ > ts->timer_expires_base = 0; > > + /* > + * Now the tick should be stopped definitely - so timer base needs to be > + * marked idle as well to not miss a newly queued timer. > + */ > + expires = timer_set_idle(basejiff, basemono, &timer_idle); > + if (!timer_idle) { > + /* > + * Do not clear tick_stopped here when it was already set - it will > + * be retained on next idle iteration when tick expired earlier > + * than expected. > + */ > + expires = basemono + TICK_NSEC; > + > + /* Undo the effect of timer_set_idle() */ > + timer_clear_idle(); Looks like you don't even need to clear ->is_idle on failure. timer_set_idle() does it for you. > + } else if (expires < ts->timer_expires) { > + ts->timer_expires = expires; > + } else { > + expires = ts->timer_expires; Is it because timer_set_idle() doesn't recalculate the next hrtimer (as opposed to get_next_timer_interrupt())? And since tick_nohz_next_event() did, the fact that ts->timer_expires has a lower value may mean there is an hrtimer to take into account and so you rather use the old calculation? If so please add a comment explaining that because it's not that obvious. It's worth noting also the side effect that the nearest timer may have been cancelled in-between and we might reprogram too-early but the event should be rare enough that we don't care. Another reason also is that cpuidle may have programmed a shallow C-state because it saw an early next expiration estimation. And if the related timer is cancelled in-between and we didn't keep the old expiration estimation, we would otherwise stop the tick for a long time with a shallow C-state. > @@ -926,7 +944,7 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) > * first call we save the current tick time, so we can restart > * the scheduler tick in nohz_restart_sched_tick. > */ > - if (!ts->tick_stopped) { > + if (!ts->tick_stopped && timer_idle) { In fact, if (!ts->tick_stopped && !timer_idle) then you should return now and avoid the reprogramming. > @@ -1950,6 +1950,40 @@ u64 get_next_timer_interrupt(unsigned long basej, u64 basem) > if (cpu_is_offline(smp_processor_id())) > return expires; > > + raw_spin_lock(&base->lock); > + nextevt = __get_next_timer_interrupt(basej, base); > + raw_spin_unlock(&base->lock); It's unfortunate we have to lock here, which means we lock twice on the idle path. But I can't think of a better way and I guess the follow-up patches rely on that. Thanks.