public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox