linux-kernel.vger.kernel.org archive mirror
 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: Mon, 28 Jun 2021 11:49:29 +0100	[thread overview]
Message-ID: <20210628104929.GA29595@arm.com> (raw)
In-Reply-To: <20210625165418.shi3gkebumqllxma@vireshk-i7>

On Friday 25 Jun 2021 at 22:24:18 (+0530), Viresh Kumar wrote:
> On 25-06-21, 09:54, Ionela Voinescu wrote:
> > Hey,
> > 
> > On Thursday 24 Jun 2021 at 18:34:18 (+0530), Viresh Kumar wrote:
> > > On 24-06-21, 10:48, Ionela Voinescu wrote:
> > > > On Monday 21 Jun 2021 at 14:49:37 (+0530), Viresh Kumar wrote:
> > > > > The Frequency Invariance Engine (FIE) is providing a frequency scaling
> > > > > correction factor that helps achieve more accurate load-tracking.
> > > > [..]
> > > > > +static void cppc_cpufreq_cpu_fie_exit(struct cpufreq_policy *policy)
> > > > > +{
> > > > > +	struct cppc_freq_invariance *cppc_fi;
> > > > > +	int cpu;
> > > > > +
> > > > > +	if (cppc_cpufreq_driver.get == hisi_cppc_cpufreq_get_rate)
> > > > > +		return;
> > > > > +
> > > > > +	/* policy->cpus will be empty here, use related_cpus instead */
> > > > > +	topology_clear_scale_freq_source(SCALE_FREQ_SOURCE_CPPC, policy->related_cpus);
> > > > > +
> > > > > +	for_each_cpu(cpu, policy->related_cpus) {
> > > > > +		cppc_fi = &per_cpu(cppc_freq_inv, cpu);
> > > > 
> > > > Do you think it might be worth having here something like:
> > > > 
> > > > 		if (!cppc_fi->cpu_data)
> > > > 			continue;
> > > > 
> > > > This would be to protect against cases where the platform does not boot
> > > > with all CPUs or the module is loaded after some have already been
> > > > offlined. Unlikely, but..
> > > 
> > > Even in that case policy->cpus will contain all offline+online CPUs (at ->init()
> > > time), isn't it ?
> > > 
> > 
> > Right, my bad. I missed cpumask_and(policy->cpus, policy->cpus,
> > cpu_online_mask) being done after init(). It logically seems a bit
> > wrong, but drivers are in control of setting policy->cpus and acting on
> > it, and in this case the driver does the right thing.
> 
> Do you want me to re-add your Reviewed-by here ?
> 

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).

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.

Thanks,
Ionela.

> +	}
> +
> +	/* Register for freq-invariance */
> +	topology_set_scale_freq_source(&cppc_sftd, policy->cpus);
> +}



> -- 
> viresh

  reply	other threads:[~2021-06-28 10:49 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 [this message]
2021-06-29  4:32             ` Viresh Kumar
2021-06-29  8:47               ` Ionela Voinescu
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=20210628104929.GA29595@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;
as well as URLs for NNTP newsgroup(s).