Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 9 Jun 2023 10:09:22 +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,
        linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
        mark.rutland@arm.com, will@kernel.org, rafael@kernel.org,
        sudeep.holla@arm.com, ionela.voinescu@arm.com, sumitg@nvidia.com,
        yang@os.amperecomputing.com, Len Brown <len.brown@intel.com>,
        vincent.guittot@linaro.org
Subject: Re: [PATCH] arm64: Provide an AMU-based version of
 arch_freq_get_on_cpu
Message-ID: <20230609043922.eyyqutbwlofqaddz@vireshk-i7>
References: <20230606155754.245998-1-beata.michalska@arm.com>
 <20230608051509.h4a6gn572mjgdusv@vireshk-i7>
 <20230608051816.2ww7ncg65qo7kcuk@vireshk-i7>
 <ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com>
Precedence: bulk

On 08-06-23, 15:45, Beata Michalska wrote:
> For those CPUs that are in full dynticks mode , the arch_freq_scale_factor will
> be basically useless (as there will be no regular sched_tick which eventually
> calls topology_scale_freq_tick()), so the code below will look for any other
> available CPU within current policy that could server as the source of the
> counters. If there is none it will fallback to cpufreq driver to provide
> current frequency.

Understood.

> There is a little bit of ambiguity around both 'cpuinfo_cur_freq' and
> 'scaling_cur_freq' and how those two are being handled on different platforms.
> If I got things right, the first one is supposed to reflect the frequency as
> obtained from  the hardware,

Yes, this must be accurate, as much as possible.

> whereas the latter is more of a sw point of view on that,

Historically, it was more about the last frequency requested by the software.
But that has changed, for example for X86 and now there is no limitation here
which disallows one to report the more accurate one.

> That could work, I guess. But then we would have 'cpuinfo_cur_freq' ==
> 'scaling_cur_freq' for platforms that do provide arch_freq_get_on_cpu,
> which might lead to more confusion as per what is the actual difference between
> the two (?)

The behavior should be same for all platforms. That's my primary concern here.
If getting same freq from both these files is okay for X86, then it should be
for ARM as well.

If the X86 commit (f8475cef9008) wasn't already merged, I would have suggested
to do this aperf/mperf thing only in cpuinfo_cur_freq() and not
scaling_cur_freq().

Maybe we can still revert back if there is no hard dependency here.

Len / Rafael ?

The question is if we should make scaling_cur_freq() to always return the last
requested frequency and make cpuinfo_cur_freq() to return the most accurate one,
preferably using aperf/mperf ?

-- 
viresh