linux-kernel - Re: [PATCH v4 1/7] topology: add a new arch_scale_freq

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 27 Oct 2023 17:19:07 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux@...linux.org.uk, catalin.marinas@....com, will@...nel.org,
        paul.walmsley@...ive.com, palmer@...belt.com,
        aou@...s.berkeley.edu, sudeep.holla@....com,
        gregkh@...uxfoundation.org, rafael@...nel.org, mingo@...hat.com,
        peterz@...radead.org, juri.lelli@...hat.com,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        viresh.kumar@...aro.org, lenb@...nel.org, robert.moore@...el.com,
        lukasz.luba@....com, ionela.voinescu@....com,
        pierre.gondois@....com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-pm@...r.kernel.org, linux-acpi@...r.kernel.org,
        acpica-devel@...ts.linuxfoundation.org, conor.dooley@...rochip.com,
        suagrfillet@...il.com, ajones@...tanamicro.com, lftan@...nel.org
Subject: Re: [PATCH v4 1/7] topology: add a new arch_scale_freq_reference

On Fri, 27 Oct 2023 at 11:31, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Vincent Guittot <vincent.guittot@...aro.org> wrote:
>
> > --- a/include/linux/arch_topology.h
> > +++ b/include/linux/arch_topology.h
> > @@ -27,6 +27,13 @@ static inline unsigned long topology_get_cpu_scale(int cpu)
> >
> >  void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity);
> >
> > +DECLARE_PER_CPU(unsigned long, capacity_ref_freq);
> > +
> > +static inline unsigned long topology_get_freq_ref(int cpu)
> > +{
> > +     return per_cpu(capacity_ref_freq, cpu);
> > +}
> > +
> >  DECLARE_PER_CPU(unsigned long, arch_freq_scale);
>
> So mind naming it in a way that expresses that this is indeed a maximum
> frequency? arch_scale_ref_freq_max or so?

This does not always have to be the max frequency of the CPU but the
frequency that has been used to compute the capacity of the CPU so
it's the "reference" frequency used for computing the capacity and
that must be used to compute  the capacity for a given frequency and
the other way. That 's why I have intentionally not used freq_max

Then other similar functions start with arch_scale_freq_something

>
> Also, is there any particular concept behind naming one new symbol
> 'freq_ref', the other 'ref_freq'? If not then please standardize on one
> variant.

no particular reason. ref_freq comes from "reference frequency" but
interfaces follows arch_scale_freq_something or
topology_*_freq_something

so we should keep freq_ref to keep interfaces aligned

>
> Thanks,
>
>         Ingo