Received-SPF: pass (google.com: domain of linux-kernel+bounces-199064-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 3 Jun 2024 17:18:11 +0530
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Beata Michalska <beata.michalska@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	rafael@kernel.org, len.brown@intel.com, ionela.voinescu@arm.com,
	vanshikonda@os.amperecomputing.com, sumitg@nvidia.com
Subject: Re: [PATCH 1/1] cpufreq: Rewire arch specific feedback for
 cpuinfo/scaling_cur_freq
Message-ID: <20240603114811.oio3uemniib5uaa2@vireshk-i7>
References: <20240603081331.3829278-1-beata.michalska@arm.com>
 <20240603081331.3829278-2-beata.michalska@arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240603081331.3829278-2-beata.michalska@arm.com>

Hi Beata,

Thanks for taking this forward.

On 03-06-24, 09:13, Beata Michalska wrote:
> Some architectures provide a way to determine an average frequency over
> a certain period of time, based on available performance monitors (AMU on
> ARM or APERF/MPERf on x86). With those at hand, enroll arch_freq_get_on_cpu
> into cpuinfo_cur_freq policy sysfs attribute handler, which is expected to
> represent the current frequency of a given CPU,as obtained by the hardware.
> This is the type of feedback that counters do provide.

Please add blank line between paragraphs, it makes it easier to read
them.

> At the same time, keep the scaling_cur_freq attribute align with the docs
> and make it provide most recently requested frequency, still allowing to
> fallback to using arch_freq_get_on_cpu for cases when cpuinfo_cur_freq is
> not available.

Please split this patch into two parts, they are very distinct changes
and should be kept separate.

> Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> ---
>  drivers/cpufreq/cpufreq.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index a45aac17c20f..3b0eabe4a983 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -758,7 +758,8 @@ static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf)
>  	ssize_t ret;
>  	unsigned int freq;
>  
> -	freq = arch_freq_get_on_cpu(policy->cpu);
> +	freq = !cpufreq_driver->get ? arch_freq_get_on_cpu(policy->cpu)
> +				    : 0;

This is getting trickier than I thought as I dived into more details
of all the changes to the file.

Rafael,

We probably need to decide on a policy for these two files, it is
getting a bit confusing.

cpuinfo_cur_freq:

The purpose of this file is abundantly clear. This returns the best
possible guess of the current hardware frequency. It should rely on
arch_freq_get_on_cpu() or ->get() to get the value.  Perhaps we can
make this available all the time, instead of conditionally on ->get()
callback (which isn't present for intel-pstate for example).

scaling_cur_freq:

This should better reflect the last requested frequency, but since a
significant time now it is trying to show what cpuinfo_cur_freq shows.

commit c034b02e213d ("cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers")
commit f8475cef9008 ("x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF")

What should we do ? I wonder if we will break some userspace tools
(which may have started relying on these changes).

>  	if (freq)
>  		ret = sprintf(buf, "%u\n", freq);
>  	else if (cpufreq_driver->setpolicy && cpufreq_driver->get)
> @@ -795,7 +796,10 @@ store_one(scaling_max_freq, max);
>  static ssize_t show_cpuinfo_cur_freq(struct cpufreq_policy *policy,
>  					char *buf)
>  {
> -	unsigned int cur_freq = __cpufreq_get(policy);
> +	unsigned int cur_freq = arch_freq_get_on_cpu(policy->cpu);
> +
> +	if (!cur_freq)
> +		cur_freq = __cpufreq_get(policy);

This change is fine and can be merged earlier I guess.

>  	if (cur_freq)
>  		return sprintf(buf, "%u\n", cur_freq);

-- 
viresh