Message ID | 20230925081139.1305766-4-lukasz.luba@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1055921vqu; Mon, 25 Sep 2023 01:25:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHv87KC3+FHq35lvWFpByEPKGWv7z+p3zbd7lFIPDZmXZnssHeZSLAH+uh8KS952hmtFXkY X-Received: by 2002:a05:6a20:430a:b0:133:1d62:dcbd with SMTP id h10-20020a056a20430a00b001331d62dcbdmr13500453pzk.28.1695630301702; Mon, 25 Sep 2023 01:25:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695630301; cv=none; d=google.com; s=arc-20160816; b=eweFERZyE+fS8ZUqImxGi1hykRHyRhYaW4Q8eFFywKdRX2uu9MrAQgduGHHcxqGozr 7Oyximo1WoegFXg5KGzUr8HeLv+ukDxl2KXH2ALgdwkJ9d9SYMvE9EvJudrpxjknxBhp xnFjfKJDMJ6Mh3DH/4VM+1lRiiiOm+o34d+7nYpNmaCWeOYyUiytNN8npEirpcvu5FPk lTHS5eOFEykM85Zw3TTlSG4OWVJ0Sr+jENOPzDSUop/SRxc4FXXUlKogpWsWGnNWmfh1 E1/pD47KKT9MYAsvsRirxtcCtATlaJGSeE1GXWVXelU6k8jhg3BWp8srS8ntggedkUwk UIEQ== 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; bh=s2hKt+ICDgnm8fA7TQUJDDmWfVUUTFmc+SHXUzozYx4=; fh=jF+j1UEDAwnYbShW3HmO1TshMsWh36Jt7pSLTP62NeE=; b=FrEN4FAH57N1L7HRFiXPluWQE4Exv+097haVbBc3OFkJvw+cxv/BVC0USWS1fv1Ou6 H0upXBOhyjnm8E7Jad9crnwNqOYbdqHQshMK6LS/0+BmmVN6y50TOvJ3q76kGYavnNZY 0PoNxkVls8JOoD/VnC06P0ZCGBN6mrDBt7MEWEFxgoJnKPhORD1F7XS8Red8ZMtTL8WT q7UMA9LG5qislRgBXXiezudqnR80X8hJQjLEbl8bgYbaOqqfPEQceCdheQuy5m+bJw4y L+cVsXSOMzHZc4zzeHmOwcScWyqfk4SqIm6qdJ77hXReTB8Y0cue+JoQG8EzVsXYHVUI RiBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id bv64-20020a632e43000000b0057745d87b50si9289160pgb.139.2023.09.25.01.25.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 01:25:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 2239280D6AFD; Mon, 25 Sep 2023 01:12:15 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232734AbjIYILm (ORCPT <rfc822;ezelljr.billy@gmail.com> + 30 others); Mon, 25 Sep 2023 04:11:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232712AbjIYIL1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 04:11:27 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A0EA6D3; Mon, 25 Sep 2023 01:11:20 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 706D21476; Mon, 25 Sep 2023 01:11:58 -0700 (PDT) Received: from e129166.arm.com (unknown [10.57.93.139]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B8D2F3F5A1; Mon, 25 Sep 2023 01:11:17 -0700 (PDT) From: Lukasz Luba <lukasz.luba@arm.com> To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org Cc: lukasz.luba@arm.com, dietmar.eggemann@arm.com, rui.zhang@intel.com, amit.kucheria@verdurent.com, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org, qyousef@layalina.io, wvw@google.com Subject: [PATCH v4 03/18] PM: EM: Find first CPU online while updating OPP efficiency Date: Mon, 25 Sep 2023 09:11:24 +0100 Message-Id: <20230925081139.1305766-4-lukasz.luba@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230925081139.1305766-1-lukasz.luba@arm.com> References: <20230925081139.1305766-1-lukasz.luba@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 groat.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 (groat.vger.email [0.0.0.0]); Mon, 25 Sep 2023 01:12:15 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777997238851893923 X-GMAIL-MSGID: 1777997238851893923 |
Series |
Introduce runtime modifiable Energy Model
|
|
Commit Message
Lukasz Luba
Sept. 25, 2023, 8:11 a.m. UTC
The Energy Model might be updated at runtime and the energy efficiency
for each OPP may change. Thus, there is a need to update also the
cpufreq framework and make it aligned to the new values. In order to
do that, use a first online CPU from the Performance Domain.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
kernel/power/energy_model.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
Comments
On Mon, Sep 25, 2023 at 10:11 AM Lukasz Luba <lukasz.luba@arm.com> wrote: > > The Energy Model might be updated at runtime and the energy efficiency > for each OPP may change. Thus, there is a need to update also the > cpufreq framework and make it aligned to the new values. In order to > do that, use a first online CPU from the Performance Domain. > > Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> > --- > kernel/power/energy_model.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c > index 42486674b834..3dafdd7731c4 100644 > --- a/kernel/power/energy_model.c > +++ b/kernel/power/energy_model.c > @@ -243,12 +243,19 @@ em_cpufreq_update_efficiencies(struct device *dev, struct em_perf_state *table) > struct em_perf_domain *pd = dev->em_pd; > struct cpufreq_policy *policy; > int found = 0; > - int i; > + int i, cpu; > > if (!_is_cpu_device(dev) || !pd) > return; > > - policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd))); > + /* Try to get a CPU which is online and in this PD */ > + cpu = cpumask_first_and(em_span_cpus(pd), cpu_active_mask); The comment talks about "online" and cpu_active_mask is used. Isn't it a bit inconsistent? > + if (cpu >= nr_cpu_ids) { > + dev_warn(dev, "EM: No online CPU for CPUFreq policy\n"); > + return; > + } > + > + policy = cpufreq_cpu_get(cpu); > if (!policy) { > dev_warn(dev, "EM: Access to CPUFreq policy failed\n"); > return; > -- > 2.25.1 >
Hi Rafael, Thank you having reviewing those patches! On 9/26/23 19:32, Rafael J. Wysocki wrote: > On Mon, Sep 25, 2023 at 10:11 AM Lukasz Luba <lukasz.luba@arm.com> wrote: >> >> The Energy Model might be updated at runtime and the energy efficiency >> for each OPP may change. Thus, there is a need to update also the >> cpufreq framework and make it aligned to the new values. In order to >> do that, use a first online CPU from the Performance Domain. >> >> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> >> --- >> kernel/power/energy_model.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c >> index 42486674b834..3dafdd7731c4 100644 >> --- a/kernel/power/energy_model.c >> +++ b/kernel/power/energy_model.c >> @@ -243,12 +243,19 @@ em_cpufreq_update_efficiencies(struct device *dev, struct em_perf_state *table) >> struct em_perf_domain *pd = dev->em_pd; >> struct cpufreq_policy *policy; >> int found = 0; >> - int i; >> + int i, cpu; >> >> if (!_is_cpu_device(dev) || !pd) >> return; >> >> - policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd))); >> + /* Try to get a CPU which is online and in this PD */ >> + cpu = cpumask_first_and(em_span_cpus(pd), cpu_active_mask); > > The comment talks about "online" and cpu_active_mask is used. Isn't > it a bit inconsistent? good point, I'll change the word to 'active' > >> + if (cpu >= nr_cpu_ids) { >> + dev_warn(dev, "EM: No online CPU for CPUFreq policy\n"); >> + return; >> + } >> + >> + policy = cpufreq_cpu_get(cpu); >> if (!policy) { >> dev_warn(dev, "EM: Access to CPUFreq policy failed\n"); >> return; >> -- >> 2.25.1 >>
Hi Lukasz, On 25/09/2023 10:11, Lukasz Luba wrote: > The Energy Model might be updated at runtime and the energy efficiency > for each OPP may change. Thus, there is a need to update also the > cpufreq framework and make it aligned to the new values. In order to > do that, use a first online CPU from the Performance Domain. I'm failing to do the connection with the description and the change. Perhaps, the changelog shall explain why 'cpu' must be replaced with the first active cpu ? > Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> > --- > kernel/power/energy_model.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c > index 42486674b834..3dafdd7731c4 100644 > --- a/kernel/power/energy_model.c > +++ b/kernel/power/energy_model.c > @@ -243,12 +243,19 @@ em_cpufreq_update_efficiencies(struct device *dev, struct em_perf_state *table) > struct em_perf_domain *pd = dev->em_pd; > struct cpufreq_policy *policy; > int found = 0; > - int i; > + int i, cpu; > > if (!_is_cpu_device(dev) || !pd) > return; > > - policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd))); > + /* Try to get a CPU which is online and in this PD */ > + cpu = cpumask_first_and(em_span_cpus(pd), cpu_active_mask); > + if (cpu >= nr_cpu_ids) { > + dev_warn(dev, "EM: No online CPU for CPUFreq policy\n"); > + return; > + } > + > + policy = cpufreq_cpu_get(cpu); > if (!policy) { > dev_warn(dev, "EM: Access to CPUFreq policy failed\n"); > return;
Hi Daniel, Thanks for looking at the patches! On 10/23/23 18:06, Daniel Lezcano wrote: > > Hi Lukasz, > > On 25/09/2023 10:11, Lukasz Luba wrote: >> The Energy Model might be updated at runtime and the energy efficiency >> for each OPP may change. Thus, there is a need to update also the >> cpufreq framework and make it aligned to the new values. In order to >> do that, use a first online CPU from the Performance Domain. > > I'm failing to do the connection with the description and the change. > > Perhaps, the changelog shall explain why 'cpu' must be replaced with the > first active cpu ? It's not a big problem now for EM, since during the boot the first CPU in the 'policy' is actually registering the EM. Although, this is an assumption and for the new runtime update of EM, we cannot assume that first is online. That's the motivation of the change. In a corner case all CPUs might be put offline, but the EM is still there because we never unregister EM for CPUs (to not race with task scheduler). I will add that description to the patch header. Thanks, Lukasz
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c index 42486674b834..3dafdd7731c4 100644 --- a/kernel/power/energy_model.c +++ b/kernel/power/energy_model.c @@ -243,12 +243,19 @@ em_cpufreq_update_efficiencies(struct device *dev, struct em_perf_state *table) struct em_perf_domain *pd = dev->em_pd; struct cpufreq_policy *policy; int found = 0; - int i; + int i, cpu; if (!_is_cpu_device(dev) || !pd) return; - policy = cpufreq_cpu_get(cpumask_first(em_span_cpus(pd))); + /* Try to get a CPU which is online and in this PD */ + cpu = cpumask_first_and(em_span_cpus(pd), cpu_active_mask); + if (cpu >= nr_cpu_ids) { + dev_warn(dev, "EM: No online CPU for CPUFreq policy\n"); + return; + } + + policy = cpufreq_cpu_get(cpu); if (!policy) { dev_warn(dev, "EM: Access to CPUFreq policy failed\n"); return;