From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
Sudeep Holla <sudeep.holla@arm.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-pm@vger.kernel.org, Qian Cai <quic_qiancai@quicinc.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 4/4] cpufreq: CPPC: Add support for frequency invariance
Date: Tue, 29 Jun 2021 09:47:37 +0100 [thread overview]
Message-ID: <20210629084737.GB2425@arm.com> (raw)
In-Reply-To: <20210629043244.xkjat5dqqjaixkii@vireshk-i7>
Hey,
On Tuesday 29 Jun 2021 at 10:02:44 (+0530), Viresh Kumar wrote:
> On 28-06-21, 11:49, Ionela Voinescu wrote:
> > To be honest I would like to have more time on this before you merge the
> > set, to better understand Qian's results and some observations I have
> > for Thunder X2 (I will share in a bit).
>
> Ideally, this code was already merged in 5.13 and would have required
> us to fix any problems as we encounter them. I did revert it because
> it caused a kernel crash and I wasn't sure if there was a sane/easy
> way of fixing that so late in the release cycle. That was the right
> thing to do then.
>
> All those issues are gone now, we may have an issue around rounding of
> counters or some hardware specific issues, it isn't clear yet.
>
> But the stuff works fine otherwise, doesn't make the kernel crash and
> it is controlled with a CONFIG_ option, so those who don't want to use
> it can still disable it.
>
> The merge window is here now, if we don't merge it now, it gets
> delayed by a full cycle (roughly two months) and if we merge it now
> and are able to narrow down the rounding issues, if there are any, we
> will have full two months to make a fix for that and still push it in
> 5.14 itself.
>
> And so I would like to get it merged in this merge window itself, it
> also makes sure more people would get to test it, like Qian was able
> to figure out a problem here for us.
>
Okay, makes sense. I have not seen this code actually do anything wrong
so far, and the issues I see on ThunderX2 point more to misbehaving
counters for this purpose. This being said, I would have probably
preferred for this feature to be disabled by default, until we've tested
more, but that won't give the chance to anyone else to test.
> > For the code, I think it's fine. I have a single observation regarding
> > the following code:
> >
> > > +static void cppc_cpufreq_cpu_fie_init(struct cpufreq_policy *policy)
> > > +{
> > > + struct cppc_freq_invariance *cppc_fi;
> > > + int cpu, ret;
> > > +
> > > + if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
> > > + return;
> > > +
> > > + for_each_cpu(cpu, policy->cpus) {
> > > + cppc_fi = &per_cpu(cppc_freq_inv, cpu);
> > > + cppc_fi->cpu = cpu;
> > > + cppc_fi->cpu_data = policy->driver_data;
> > > + kthread_init_work(&cppc_fi->work, cppc_scale_freq_workfn);
> > > + init_irq_work(&cppc_fi->irq_work, cppc_irq_work);
> > > +
> > > + ret = cppc_get_perf_ctrs(cpu, &cppc_fi->prev_perf_fb_ctrs);
> > > + if (ret) {
> > > + pr_warn("%s: failed to read perf counters for cpu:%d: %d\n",
> > > + __func__, cpu, ret);
> > > + return;
> > > + }
> >
> > For this condition above, think about a scenario where reading counters
> > for offline CPUs returns an error. I'm not sure if that can happen, to
> > be honest. That would mean here that you will never initialise the freq
> > source unless all CPUs in the policy are online at policy creation.
> >
> > My recommendation is to warn about the failed read of perf counters but
> > only return from this function if the target CPU is online as well when
> > reading counters fails.
> >
> > This is probably a nit, so I'll let you decide if you want to do something
> > about this.
>
> That is a very good observation actually. Thanks for that. This is how
> I fixed it.
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index d688877e8fbe..f6540068d0fe 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -171,7 +171,13 @@ static void cppc_cpufreq_cpu_fie_init(struct cpufreq_policy *policy)
> if (ret) {
> pr_warn("%s: failed to read perf counters for cpu:%d: %d\n",
> __func__, cpu, ret);
> - return;
> +
> + /*
> + * Don't abort if the CPU was offline while the driver
> + * was getting registered.
> + */
> + if (cpu_online(cpu))
> + return;
> }
> }
>
> --
Thanks!
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Ionela.
> viresh
next prev parent reply other threads:[~2021-06-29 8:47 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 9:19 [PATCH V3 0/4] cpufreq: cppc: Add support for frequency invariance Viresh Kumar
2021-06-21 9:19 ` [PATCH V3 1/4] cpufreq: cppc: Fix potential memleak in cppc_cpufreq_cpu_init Viresh Kumar
2021-06-23 13:44 ` Ionela Voinescu
2021-06-24 2:08 ` Viresh Kumar
2021-06-24 2:10 ` [PATCH V3.1 " Viresh Kumar
2021-06-25 10:33 ` Ionela Voinescu
2021-06-21 9:19 ` [PATCH V3 2/4] cpufreq: cppc: Pass structure instance by reference Viresh Kumar
2021-06-23 13:45 ` Ionela Voinescu
2021-06-24 2:22 ` Viresh Kumar
2021-06-25 10:30 ` Ionela Voinescu
2021-06-21 9:19 ` [PATCH V3 3/4] arch_topology: Avoid use-after-free for scale_freq_data Viresh Kumar
2021-06-23 13:50 ` Ionela Voinescu
2021-06-21 9:19 ` [PATCH V3 4/4] cpufreq: CPPC: Add support for frequency invariance Viresh Kumar
2021-06-24 9:48 ` Ionela Voinescu
2021-06-24 13:04 ` Viresh Kumar
2021-06-25 8:54 ` Ionela Voinescu
2021-06-25 16:54 ` Viresh Kumar
2021-06-28 10:49 ` Ionela Voinescu
2021-06-29 4:32 ` Viresh Kumar
2021-06-29 8:47 ` Ionela Voinescu [this message]
2021-06-29 8:53 ` Viresh Kumar
2021-06-21 20:48 ` [PATCH V3 0/4] cpufreq: cppc: " Qian Cai
2021-06-22 6:52 ` Viresh Kumar
2021-06-23 4:16 ` Viresh Kumar
2021-06-23 12:57 ` Qian Cai
2021-06-24 2:54 ` Viresh Kumar
2021-06-24 9:49 ` Vincent Guittot
2021-06-24 10:48 ` Ionela Voinescu
2021-06-24 11:15 ` Vincent Guittot
2021-06-24 11:23 ` Ionela Voinescu
2021-06-24 11:59 ` Vincent Guittot
2021-06-24 15:17 ` Qian Cai
2021-06-25 10:21 ` Ionela Voinescu
2021-06-25 13:31 ` Qian Cai
2021-06-25 14:37 ` Ionela Voinescu
2021-06-25 16:56 ` Qian Cai
2021-06-26 2:29 ` Qian Cai
2021-06-26 13:41 ` Qian Cai
2021-06-29 4:55 ` Viresh Kumar
2021-06-29 4:52 ` Viresh Kumar
2021-06-29 9:06 ` Ionela Voinescu
2021-06-29 13:38 ` Qian Cai
2021-06-29 4:45 ` Viresh Kumar
2021-06-24 20:44 ` Qian Cai
2021-06-28 11:54 ` Ionela Voinescu
2021-06-28 12:14 ` Vincent Guittot
2021-06-28 12:17 ` Vincent Guittot
2021-06-28 13:08 ` Ionela Voinescu
2021-06-28 21:37 ` Ionela Voinescu
2021-06-29 8:45 ` Vincent Guittot
2021-06-29 5:20 ` Viresh Kumar
2021-06-29 8:46 ` Ionela Voinescu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210629084737.GB2425@arm.com \
--to=ionela.voinescu@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quic_qiancai@quicinc.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.