Message ID | 20221025135850.51044-2-anna-maria@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1024140wru; Tue, 25 Oct 2022 07:02:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5MYIIrrrGL5SbcqS9QiKmkWYIEWPhHFOLFZMdnYaCFAjD43AY6OE44XO5nFMQ7Hz+LPVay X-Received: by 2002:a17:906:fe46:b0:73d:939a:ec99 with SMTP id wz6-20020a170906fe4600b0073d939aec99mr33081287ejb.169.1666706530160; Tue, 25 Oct 2022 07:02:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666706530; cv=none; d=google.com; s=arc-20160816; b=DN1LqE0I7pfm0lXMeuRUCxV1y0MPeeceF50I5B2vdD7e7S4IVWH8PNQ7kS4L/k0Mmf Ab5WUOVPSkd3igHmC8qsXSKhCki3GG5SNt1jzGiJx0N1lW0jYx/NEp87jBhLMokpxBbq G7KHlF3pNsqhXovpr6bCKL9CyO8Qn7MqqLEwAE/hmUGVLCRYfiWrgQns4xZipyVUq9qi 3QBg8QF2nnMYE34KCP3ayeYw/nDo8n5vx6LUtWpqGpiyIs4gk4cMtpmsx3oSNqUex5aG RfJ1gZiH5UJ/TFL7aijbEvMHNKOUKQP/7uM+i5KTlSaifff3Z3djLw2OaRQO7vFkt69S YCQw== 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=JsI07DTqXjWlRwYDoljjsPLtGx2xh4qIy28E4h8N7no=; b=A8ydwKGvedCRfxfLK8rfNUSx0MpqwYN6hiM+m5/jo9J8mkZPH4j1Gjn6c6iq5I0326 YCEJpPyREpBgmDBu/5sLB8JEaqKAcPj8F8vsIbkYFAdSx8+MejT1G9LHPUgT4zb9aVDk KC5Q/zTGINLTuZIrDLHypzO/mx+USPOrtE954HbGcmPSAIfr+M+fwMUkOIkVJLJM7t+s YjhH/GIVYqfzuv8XvsfCbbJw/0o+2hMoxT7au7cITTmKJC9iAG5cCr3qkrRsCv6wbRrE cybYkq1/nwA5CXztg1oHsYhXjwwyhIH8rniQ3cn7ChPGt2h3vwnboHgCcSIpa5g5fzc7 l7gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=T3EsepFn; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s1-20020a056402520100b00461bbc0f917si3254300edd.605.2022.10.25.07.01.34; Tue, 25 Oct 2022 07:02:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=T3EsepFn; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231945AbiJYN7d (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Tue, 25 Oct 2022 09:59:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231191AbiJYN7Y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Oct 2022 09:59:24 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D25561B9CD; Tue, 25 Oct 2022 06:59:22 -0700 (PDT) From: Anna-Maria Behnsen <anna-maria@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1666706361; 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=JsI07DTqXjWlRwYDoljjsPLtGx2xh4qIy28E4h8N7no=; b=T3EsepFnG1VEPakgQAPv6utfeISI5b9SCb3qu9nw9yeGr8jw8t1zR6Dx6ch73PUNFHVOGL oqi15SnAg6HRSDAkl4rHMmQDmCPs6a9Lv63YmgSPuSPwPNSps9UbplBD71AHpxg2pJhoxM FyKJ6I+g+ewtLZORJV916KEkkleW6We3dblqJb1P61KSpLSm5qD968Gg2KoZJ148/HVXoU TIw427aYJT6plp81tvDQn1+JvmlMVHx6z/OXTHK8T9S81zxHoAeP4HroqZjYTVa+HVrrka zTpa7evXpC5fGDXUF91xC6m66JO487MZ65rfWuv1Y0eNCYhcD7momR1AF1QKSQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1666706361; 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=JsI07DTqXjWlRwYDoljjsPLtGx2xh4qIy28E4h8N7no=; b=i7qAAP55lL27scwdgwJ3teCam7iQjkFLDDmuZcmI7LTkktrsPSWpugrETm6inYdHUHJQBi M/D/ekZWd+6fl2BQ== To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org>, John Stultz <john.stultz@linaro.org>, Eric Dumazet <edumazet@google.com>, Thomas Gleixner <tglx@linutronix.de>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, linux-pm@vger.kernel.org, Arjan van de Ven <arjan@infradead.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Frederic Weisbecker <fweisbec@gmail.com>, Rik van Riel <riel@redhat.com>, Anna-Maria Behnsen <anna-maria@linutronix.de>, "Rafael J . Wysocki" <rafael@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>, Michael Ellerman <mpe@ellerman.id.au> Subject: [PATCH v3 01/17] cpufreq: Prepare timer flags for hierarchical timer pull model Date: Tue, 25 Oct 2022 15:58:34 +0200 Message-Id: <20221025135850.51044-2-anna-maria@linutronix.de> In-Reply-To: <20221025135850.51044-1-anna-maria@linutronix.de> References: <20221025135850.51044-1-anna-maria@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747668466599433141?= X-GMAIL-MSGID: =?utf-8?q?1747668466599433141?= |
Series |
timer: Move from a push remote at enqueue to a pull at expiry model
|
|
Commit Message
Anna-Maria Behnsen
Oct. 25, 2022, 1:58 p.m. UTC
Note: This is a proposal only. I was waiting on input how to change this
driver properly to use the already existing infrastructure. See therfore
the thread on linux-pm mailinglist:
https://lore.kernel.org/linux-pm/4c99f34b-40f1-e6cc-2669-7854b615b5fd@linutronix.de/
gpstates timer is the only timer using TIMER_PINNED and TIMER_DEFERRABLE
flag. When moving to hierarchical timer pull model, pinned and deferrable
timers are stored in separate bases.
To ensure gpstates timer always expires on the CPU where it is pinned to,
keep only TIMER_PINNED flag and drop TIMER_DEFERRABLE flag.
While at it, rewrite comment explaining the rule for timer expiry for the
next interval and fix whitespace damages.
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: linux-pm@vger.kernel.org
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
---
drivers/cpufreq/powernv-cpufreq.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
Comments
On Tue, Oct 25, 2022 at 03:58:34PM +0200, Anna-Maria Behnsen wrote: > Note: This is a proposal only. I was waiting on input how to change this > driver properly to use the already existing infrastructure. See therfore > the thread on linux-pm mailinglist: > https://lore.kernel.org/linux-pm/4c99f34b-40f1-e6cc-2669-7854b615b5fd@linutronix.de/ > > gpstates timer is the only timer using TIMER_PINNED and TIMER_DEFERRABLE > flag. When moving to hierarchical timer pull model, pinned and deferrable > timers are stored in separate bases. > > To ensure gpstates timer always expires on the CPU where it is pinned to, > keep only TIMER_PINNED flag and drop TIMER_DEFERRABLE flag. OTOH there are deferrable timers out there that expect to run on a specific CPU, because there are always queued with add_timer_on(). For example workqueues using DECLARE_DEFERRABLE_WORK() that are queued with queue_delayed_work_on(). Like vmstat(). Those are not explicitely pinned because they don't rely on __mod_timer() but they expect CPU affinity. Thanks. > > While at it, rewrite comment explaining the rule for timer expiry for the > next interval and fix whitespace damages. > > Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de> > Cc: linux-pm@vger.kernel.org > Cc: Rafael J. Wysocki <rafael@kernel.org> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: Michael Ellerman <mpe@ellerman.id.au> > --- > drivers/cpufreq/powernv-cpufreq.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c > index fddbd1ea1635..08d6bd54539d 100644 > --- a/drivers/cpufreq/powernv-cpufreq.c > +++ b/drivers/cpufreq/powernv-cpufreq.c > @@ -640,18 +640,18 @@ static inline int calc_global_pstate(unsigned int elapsed_time, > return highest_lpstate_idx + index_diff; > } > > -static inline void queue_gpstate_timer(struct global_pstate_info *gpstates) > +static inline void queue_gpstate_timer(struct global_pstate_info *gpstates) > { > unsigned int timer_interval; > > /* > - * Setting up timer to fire after GPSTATE_TIMER_INTERVAL ms, But > - * if it exceeds MAX_RAMP_DOWN_TIME ms for ramp down time. > - * Set timer such that it fires exactly at MAX_RAMP_DOWN_TIME > - * seconds of ramp down time. > + * Timer should expire next time after GPSTATE_TIMER_INTERVAL. If > + * the resulting interval (elapsed time + interval) between last > + * and next timer expiry is greater than MAX_RAMP_DOWN_TIME, ensure > + * it is maximum MAX_RAMP_DOWN_TIME when queueing the next timer. > */ > if ((gpstates->elapsed_time + GPSTATE_TIMER_INTERVAL) > - > MAX_RAMP_DOWN_TIME) > + > MAX_RAMP_DOWN_TIME) > timer_interval = MAX_RAMP_DOWN_TIME - gpstates->elapsed_time; > else > timer_interval = GPSTATE_TIMER_INTERVAL; > @@ -865,8 +865,7 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy) > > /* initialize timer */ > gpstates->policy = policy; > - timer_setup(&gpstates->timer, gpstate_timer_handler, > - TIMER_PINNED | TIMER_DEFERRABLE); > + timer_setup(&gpstates->timer, gpstate_timer_handler, TIMER_PINNED); > gpstates->timer.expires = jiffies + > msecs_to_jiffies(GPSTATE_TIMER_INTERVAL); > spin_lock_init(&gpstates->gpstate_lock); > -- > 2.30.2 >
On Wed, 26 Oct 2022, Frederic Weisbecker wrote: > On Tue, Oct 25, 2022 at 03:58:34PM +0200, Anna-Maria Behnsen wrote: > > Note: This is a proposal only. I was waiting on input how to change this > > driver properly to use the already existing infrastructure. See therfore > > the thread on linux-pm mailinglist: > > https://lore.kernel.org/linux-pm/4c99f34b-40f1-e6cc-2669-7854b615b5fd@linutronix.de/ > > > > gpstates timer is the only timer using TIMER_PINNED and TIMER_DEFERRABLE > > flag. When moving to hierarchical timer pull model, pinned and deferrable > > timers are stored in separate bases. > > > > To ensure gpstates timer always expires on the CPU where it is pinned to, > > keep only TIMER_PINNED flag and drop TIMER_DEFERRABLE flag. > > OTOH there are deferrable timers out there that expect to run on a > specific CPU, because there are always queued with add_timer_on(). > > For example workqueues using DECLARE_DEFERRABLE_WORK() that are queued > with queue_delayed_work_on(). Like vmstat(). > > Those are not explicitely pinned because they don't rely on __mod_timer() > but they expect CPU affinity. > You are right. In contrast to the original plan, I'm not able (yet) to remove the deferrable timers completely. But all timers using the add_timer_on() path need the TIMER_PINNED flag. Then three timer bases per CPU will be available: - global base (TIMER_PINNED is not set) - local base (TIMER_PINNED is set but not TIMER_DEFERRABLE) - deferrable pinned base (TIMER_PINNED and TIMER_DEFERRABLE is set) The logic stays the same as already implemented in patch queue: Timers in global base will not prevent CPU from going idle. When the CPU has the migrator duty, timers in hierarchy are taken into account. Timers in local base force the CPU to wake up. Timers in the deferrable pinned base are not taken into account when going idle. With this, the rework of cpufreq driver is no longer required - the timer will end up in deferrable pinned base the same with vmstat. Thanks, Anna-Maria
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c index fddbd1ea1635..08d6bd54539d 100644 --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -640,18 +640,18 @@ static inline int calc_global_pstate(unsigned int elapsed_time, return highest_lpstate_idx + index_diff; } -static inline void queue_gpstate_timer(struct global_pstate_info *gpstates) +static inline void queue_gpstate_timer(struct global_pstate_info *gpstates) { unsigned int timer_interval; /* - * Setting up timer to fire after GPSTATE_TIMER_INTERVAL ms, But - * if it exceeds MAX_RAMP_DOWN_TIME ms for ramp down time. - * Set timer such that it fires exactly at MAX_RAMP_DOWN_TIME - * seconds of ramp down time. + * Timer should expire next time after GPSTATE_TIMER_INTERVAL. If + * the resulting interval (elapsed time + interval) between last + * and next timer expiry is greater than MAX_RAMP_DOWN_TIME, ensure + * it is maximum MAX_RAMP_DOWN_TIME when queueing the next timer. */ if ((gpstates->elapsed_time + GPSTATE_TIMER_INTERVAL) - > MAX_RAMP_DOWN_TIME) + > MAX_RAMP_DOWN_TIME) timer_interval = MAX_RAMP_DOWN_TIME - gpstates->elapsed_time; else timer_interval = GPSTATE_TIMER_INTERVAL; @@ -865,8 +865,7 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy) /* initialize timer */ gpstates->policy = policy; - timer_setup(&gpstates->timer, gpstate_timer_handler, - TIMER_PINNED | TIMER_DEFERRABLE); + timer_setup(&gpstates->timer, gpstate_timer_handler, TIMER_PINNED); gpstates->timer.expires = jiffies + msecs_to_jiffies(GPSTATE_TIMER_INTERVAL); spin_lock_init(&gpstates->gpstate_lock);