Message ID | 20231201092654.34614-20-anna-maria@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp991959vqy; Fri, 1 Dec 2023 01:28:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IH5ufW35eftyNCEytzOziyt2m7nLbNsxa3SOhyZ5uYRWpQhdvJejByo5UoygydteUvfJnER X-Received: by 2002:a05:6a21:998e:b0:18c:a9d3:4f96 with SMTP id ve14-20020a056a21998e00b0018ca9d34f96mr18627123pzb.32.1701422912554; Fri, 01 Dec 2023 01:28:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701422912; cv=none; d=google.com; s=arc-20160816; b=VGd0feTPqvhNk21mhWoEKwvz6jwuVCU+SYhvmzUpjyhl47nnT0owwRrvGds0klrWl5 LqPgtorx62u7sMUrEmH9ifIgpMnjqQI+gqR8kPzinXMSyAk4dXO0G77pdQu0OcOcskaP 0kLPoKwz7SzKIN4YPf9EhMEyYFhaOLnmhHFz/ziZEdiUT+FyC1/GCrhX+V1tsGsAjCmv YHmHLjIwJ17w8sO3VtyHImT1lvjjuxhXMeZaOBOkAp2xjnBWxgrVJ1dayAbSIrLQT2dj /P0so760fd6IXHepb/ZCurjRwjx4l0tIhCCtRb9jZ8wG4KhmPL9RzoT6ZVNTCYvhz60A FIrA== 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:dkim-signature :dkim-signature:from; bh=1gYaVFuPoy5UW7Ox9DtRT+q6BrvDn/y7/UpgVZp13oQ=; fh=PG6uS4TiiUSDyl8D/joYkWbwCgDm4ug0ir2h7tHBJXQ=; b=FoXj0jo04RZgSUvDznRuFXh7Hl7lGRHxMpK/VlhFYZzZjB5PKchNAFvMvat5G1kOIu 7Nd2R7xF0bIRIz5EiQuefg6Au56dXZsKxL3N4SaTz1YZZC43fWR1xXxE2D96BsdzzLN/ xCyyUgPF/ELydRN5BfW7IRV13EzlCkyoqVuHuSHDL5Y1LdP+ZgqDnxCUhrVeEmHy4g4N qZ1GDNma6wkCNOJWYkSZs28wPusHCmAi6TsG3dx9/NA4lxMdOtepKBa9xXXiavObkWSH vtQF0zbaFk+DHq4MrweguFen4gFc9fIrQWp0FpZwSm8Rvuxwak1dYIjRV+ucJ6fQ/X91 1PIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="PAq/TcXi"; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id gc21-20020a17090b311500b00285b97c7d6fsi5377878pjb.141.2023.12.01.01.28.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 01:28:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="PAq/TcXi"; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 19D38815CDA3; Fri, 1 Dec 2023 01:28:30 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378205AbjLAJ2R (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Fri, 1 Dec 2023 04:28:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378145AbjLAJ1x (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 1 Dec 2023 04:27:53 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94EEC19BA for <linux-kernel@vger.kernel.org>; Fri, 1 Dec 2023 01:27:21 -0800 (PST) From: Anna-Maria Behnsen <anna-maria@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1701422840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1gYaVFuPoy5UW7Ox9DtRT+q6BrvDn/y7/UpgVZp13oQ=; b=PAq/TcXiBr3vZ/bkP9wgwgb+f+unPFLW+vAXzRt+6k89zhx2iT2ghtEO3DDzYolFQNZOSV Dca4vwfGYpZBDms4ilYjqB8hCoVv4jZuEZgU0QzHrKNk/pGZQgajCQo0/Aek2w1bmQfPC/ 5j4+ejwW8gzdI+22p3K0gko4dopIc4xJmfa4JJaKSzGLhapw4mozgr5/AE8c84BjKIWsFW +0VqVw+gdHK/+qHoLWNSRGcBUSLz/GJFhC9yJO/P42yvOvG6j1Jx5SEdqYP1ysDymvxjUo YmERn21/1bO1ajNJRbIUovB2JPf81tx2v0ls0z/9nr6Djonmo1rE3Eqao/xqcQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1701422840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1gYaVFuPoy5UW7Ox9DtRT+q6BrvDn/y7/UpgVZp13oQ=; b=CMqrDpwUb7eN+9HpKDodq8mpQY1W2MPkSZ2JjOUoBa5afMYeE9Fk/f8rGRM2JQgxmB4BPk YINYi1ThYLanF4CA== To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org>, John Stultz <jstultz@google.com>, Thomas Gleixner <tglx@linutronix.de>, Eric Dumazet <edumazet@google.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Arjan van de Ven <arjan@infradead.org>, "Paul E . McKenney" <paulmck@kernel.org>, Frederic Weisbecker <frederic@kernel.org>, Rik van Riel <riel@surriel.com>, Steven Rostedt <rostedt@goodmis.org>, Sebastian Siewior <bigeasy@linutronix.de>, Giovanni Gherdovich <ggherdovich@suse.cz>, Lukasz Luba <lukasz.luba@arm.com>, "Gautham R . Shenoy" <gautham.shenoy@amd.com>, Srinivas Pandruvada <srinivas.pandruvada@intel.com>, K Prateek Nayak <kprateek.nayak@amd.com>, Anna-Maria Behnsen <anna-maria@linutronix.de> Subject: [PATCH v9 19/32] timers: add_timer_on(): Make sure TIMER_PINNED flag is set Date: Fri, 1 Dec 2023 10:26:41 +0100 Message-Id: <20231201092654.34614-20-anna-maria@linutronix.de> In-Reply-To: <20231201092654.34614-1-anna-maria@linutronix.de> References: <20231201092654.34614-1-anna-maria@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email 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 (lipwig.vger.email [0.0.0.0]); Fri, 01 Dec 2023 01:28:30 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784071232353346232 X-GMAIL-MSGID: 1784071232353346232 |
Series |
timers: Move from a push remote at enqueue to a pull at expiry model
|
|
Commit Message
Anna-Maria Behnsen
Dec. 1, 2023, 9:26 a.m. UTC
When adding a timer to the timer wheel using add_timer_on(), it is an implicitly pinned timer. With the timer pull at expiry time model in place, TIMER_PINNED flag is required to make sure timers end up in proper base. Add TIMER_PINNED flag unconditionally when add_timer_on() is executed. Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> --- kernel/time/timer.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
Comments
On 2023-12-01 10:26:41 [+0100], Anna-Maria Behnsen wrote: > When adding a timer to the timer wheel using add_timer_on(), it is an > implicitly pinned timer. With the timer pull at expiry time model in place, > TIMER_PINNED flag is required to make sure timers end up in proper base. > > Add TIMER_PINNED flag unconditionally when add_timer_on() is executed. This is odd. I have some vague memory that this was already the case. Otherwise all add_timer_on() users without TIMER_PINNED may get it wrong due to optimisation. Looking at git history it was never the case and I can't confuse it with hrtimer since it never supported the "_on()" feature… At least the mix timer in drivers/char/random.c is not using the PINNED flag with _on(). So this was wrong then?… Sebastian
Sebastian Siewior <bigeasy@linutronix.de> writes: > On 2023-12-01 10:26:41 [+0100], Anna-Maria Behnsen wrote: >> When adding a timer to the timer wheel using add_timer_on(), it is an >> implicitly pinned timer. With the timer pull at expiry time model in place, >> TIMER_PINNED flag is required to make sure timers end up in proper base. >> >> Add TIMER_PINNED flag unconditionally when add_timer_on() is executed. > > This is odd. I have some vague memory that this was already the case. > Otherwise all add_timer_on() users without TIMER_PINNED may get it wrong > due to optimisation. Which optimisation are you talking about? Are you talking about the heuristic for finding the best CPU in get_target_base()? This heuristic is not used for add_timer_on(). > Looking at git history it was never the case and I > can't confuse it with hrtimer since it never supported the "_on()" > feature… > At least the mix timer in drivers/char/random.c is not using the PINNED > flag with _on(). So this was wrong then?… No, this it is not wrong, as at the moment timers expires always on the CPU where they have been queued. So when a timer should be queued on a dedicated CPU several approaches are valid: - using add_timer_on() with or without TIMER_PINNED flag set to enqueue timers on any specified CPU - use add_timer()/mod_timer()/... with TIMER_PINNED flag set - but this only works to enqueue timer on this CPU! When using the add_timer()/mod_timer()/... functions without TIMER_PINNED flag, the heuristic is used for finding the best CPU. So without the timer pull model the change doesn't hurt. But with the timer pull model in place, it is required to keep the pinned and non pinned timers in separate per CPU wheels (local wheel = TIMER_PINNED is set; global wheel = TIMER_PINNED is not set). So without this change but with the timer pull model, the mix timer of random.c would be enqueued on the dedicated CPU, but it would end up in the wrong wheel (global wheel). And then the timer could also expire on another CPUs as the global wheels are handled by the migrator when the CPU is idle. Does this makes it a little more clear, why the change is required and why it is also valid right now? Thanks, Anna-Maria
On 2023-12-06 10:57:57 [+0100], Anna-Maria Behnsen wrote: > Sebastian Siewior <bigeasy@linutronix.de> writes: > > > On 2023-12-01 10:26:41 [+0100], Anna-Maria Behnsen wrote: > >> When adding a timer to the timer wheel using add_timer_on(), it is an > >> implicitly pinned timer. With the timer pull at expiry time model in place, > >> TIMER_PINNED flag is required to make sure timers end up in proper base. > >> > >> Add TIMER_PINNED flag unconditionally when add_timer_on() is executed. > > > > This is odd. I have some vague memory that this was already the case. > > Otherwise all add_timer_on() users without TIMER_PINNED may get it wrong > > due to optimisation. > > Which optimisation are you talking about? Are you talking about the > heuristic for finding the best CPU in get_target_base()? This heuristic > is not used for add_timer_on(). Yes, true. And nobody probably mixes add_timer_on() and mod_timer(). > Does this makes it a little more clear, why the change is required and > why it is also valid right now? Yes, all good. Thanks. > Thanks, > > Anna-Maria Sebastian
Sebastian Siewior <bigeasy@linutronix.de> writes: > On 2023-12-06 10:57:57 [+0100], Anna-Maria Behnsen wrote: >> Sebastian Siewior <bigeasy@linutronix.de> writes: >> >> > On 2023-12-01 10:26:41 [+0100], Anna-Maria Behnsen wrote: >> >> When adding a timer to the timer wheel using add_timer_on(), it is an >> >> implicitly pinned timer. With the timer pull at expiry time model in place, >> >> TIMER_PINNED flag is required to make sure timers end up in proper base. >> >> >> >> Add TIMER_PINNED flag unconditionally when add_timer_on() is executed. >> > >> > This is odd. I have some vague memory that this was already the case. >> > Otherwise all add_timer_on() users without TIMER_PINNED may get it wrong >> > due to optimisation. >> >> Which optimisation are you talking about? Are you talking about the >> heuristic for finding the best CPU in get_target_base()? This heuristic >> is not used for add_timer_on(). > > Yes, true. And nobody probably mixes add_timer_on() and mod_timer(). Workqueue mixes add_timer_on() and add_timer(). But therefore the add_timer_global() function is introduced in patch 17 which drops the TIMER_PINNED flag. In patch 18 the add_timer() in workqueue code is replaced by the new function. Thanks, Anna-Maria
diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 0ce0e6b25482..ea94479ee7e2 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1284,7 +1284,10 @@ EXPORT_SYMBOL(add_timer_global); * @timer: The timer to be started * @cpu: The CPU to start it on * - * Same as add_timer() except that it starts the timer on the given CPU. + * Same as add_timer() except that it starts the timer on the given CPU and + * the TIMER_PINNED flag is set. When timer shouldn't be a pinned timer in + * the next round, add_timer_global() should be used instead as it unsets + * the TIMER_PINNED flag. * * See add_timer() for further details. */ @@ -1298,6 +1301,9 @@ void add_timer_on(struct timer_list *timer, int cpu) if (WARN_ON_ONCE(timer_pending(timer))) return; + /* Make sure timer flags have TIMER_PINNED flag set */ + timer->flags |= TIMER_PINNED; + new_base = get_timer_cpu_base(timer->flags, cpu); /*