linux-kernel - Re: [PATCH] arm64: Provide an AMU-based version of arch_freq_get_on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZIwx+4zVzgKGLcS3@e120325.cambridge.arm.com>
Date:   Fri, 16 Jun 2023 10:57:15 +0100
From:   Beata Michalska <beata.michalska@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
        mark.rutland@....com, will@...nel.org, rafael@...nel.org,
        sudeep.holla@....com, ionela.voinescu@....com, sumitg@...dia.com,
        yang@...amperecomputing.com, Len Brown <len.brown@...el.com>,
        vincent.guittot@...aro.org
Subject: Re: [PATCH] arm64: Provide an AMU-based version of
 arch_freq_get_on_cpu

On Fri, Jun 09, 2023 at 10:09:22AM +0530, Viresh Kumar wrote:
> 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's my observation as well - thank you for clarifying.
> > 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.
> 
I agree it would be good to align the behaviour here.
I guess we should wait for more input on what we can and cannot do for x86.

---
BR
B.
> 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