From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47FBCC4167B for ; Wed, 6 Dec 2023 09:47:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377331AbjLFJrt (ORCPT ); Wed, 6 Dec 2023 04:47:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377348AbjLFJrl (ORCPT ); Wed, 6 Dec 2023 04:47:41 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E4E110D4 for ; Wed, 6 Dec 2023 01:47:39 -0800 (PST) Date: Wed, 6 Dec 2023 10:47:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1701856057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dZL4xpIW5Xbtis3hnUiCyn0G7mTR94oGieX73+hE5Tk=; b=RemarrlJFGANeBLplMKNzkZVPTgIXVgK0dnGTqZRpWRUqYuPNg/igS6wMk7e9a0ywmooih E8hIqIr8R7+MShTnVtcZAT52YYNbPlrbT7WnPcUGXKSxK8qlpV0HB6PBAPLKMYreUbN7l/ kXGyL+1mc6S8vz/bZy53JD0DxWMzleHzS9WqHZ/Ua6g3x7veJh2bNdp0zsT8QwBtqiImuU ePXAGipjEoSKs5jrQgk6DZspsnsspss9zmjvXdcBBXROPv3BxwEWN7rbXk2j+VkkaftBO3 5dEzCBM7PruJi5aRi+CN1bBDQPjmWGIEmcGgPZZjzUJuFqYPGoQXGUOooewa6Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1701856057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dZL4xpIW5Xbtis3hnUiCyn0G7mTR94oGieX73+hE5Tk=; b=z4zP1RhM6n+SbF00Fk8AL8K/95cDBJ1CT8SFh0vLFGW1f56DUpS23k285R6aMNF9pyEemp Eol2yJnCC/pv0/Dg== From: Sebastian Siewior 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" , Frederic Weisbecker , Rik van Riel , Steven Rostedt , Giovanni Gherdovich , Lukasz Luba , "Gautham R . Shenoy" , Srinivas Pandruvada , K Prateek Nayak , Richard Cochran Subject: Re: [PATCH v9 23/32] timers: Retrieve next expiry of pinned/non-pinned timers separately Message-ID: <20231206094735.HMFIZlHa@linutronix.de> References: <20231201092654.34614-1-anna-maria@linutronix.de> <20231201092654.34614-24-anna-maria@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20231201092654.34614-24-anna-maria@linutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-12-01 10:26:45 [+0100], Anna-Maria Behnsen wrote: > For the conversion of the NOHZ timer placement to a pull at expiry time > model it's required to have separate expiry times for the pinned and the > non-pinned (movable) timers. Therefore struct timer_events is introduced. >=20 > No functional change >=20 > Originally-by: Richard Cochran (linutronix GmbH) > Signed-off-by: Anna-Maria Behnsen > Reviewed-by: Frederic Weisbecker =E2=80=A6 > index 366ea26ce3ba..0d53d853ae22 100644 > --- a/kernel/time/timer.c > +++ b/kernel/time/timer.c =E2=80=A6 > @@ -2022,13 +2028,31 @@ static inline u64 __get_next_timer_interrupt(unsi= gned long basej, u64 basem, > =20 > nextevt =3D local_first ? nextevt_local : nextevt_global; > =20 > - if (base_local->timers_pending || base_global->timers_pending) { > + /* > + * If the @nextevt is at max. one tick away, use @nextevt and store > + * it in the local expiry value. The next global event is irrelevant in > + * this case and can be left as KTIME_MAX. > + */ > + if (time_before_eq(nextevt, basej + 1)) { > /* If we missed a tick already, force 0 delta */ > if (time_before(nextevt, basej)) > nextevt =3D basej; > - expires =3D basem + (u64)(nextevt - basej) * TICK_NSEC; > + tevt.local =3D basem + (u64)(nextevt - basej) * TICK_NSEC; > + goto unlock; You claim "No functional change" in the patch description. However if you take the shortcut here you don't update `idle' if set and you don't __forward_timer_base(). The `idle` parameter doesn't matter because it was false and will remain false as per current logic. But what about the forward of the timer base? It is probably not real problem since the next add/mod timer call will forward it. Sebastian