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: <20200701095414.2wjcnyhndgcedk2q@vireshk-i7>
Date:   Wed, 1 Jul 2020 16:16:19 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Ionela Voinescu <ionela.voinescu@....com>
Cc:     rjw@...ysocki.net, catalin.marinas@....com, sudeep.holla@....com,
        will@...nel.org, linux@...linux.org.uk, valentin.schneider@....com,
        mingo@...hat.com, peterz@...radead.org, dietmar.eggemann@....com,
        linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Liviu Dudau <liviu.dudau@....com>
Subject: Re: [PATCH 4/8] cpufreq,vexpress-spc: fix Frequency Invariance (FI)
 for bL switching

On 01-07-20, 10:07, Ionela Voinescu wrote:
> In the majority of cases, the index argument to cpufreq's target_index()
> is meant to identify the frequency that is requested from the hardware,
> according to the frequency table: policy->freq_table[index].frequency.
> 
> After successfully requesting it from the hardware, this value, together
> with the maximum hardware frequency (policy->cpuinfo.max_freq) are used
> as arguments to arch_set_freq_scale(), in order to set the task scheduler
> frequency scale factor. This is a normalized indication of a CPU's
> current performance.
> 
> But for the vexpress-spc-cpufreq driver, when big.LITTLE switching [1]
> is enabled, there are three issues with using the above information for
> setting the FI scale factor:
> 
>  - cur_freq: policy->freq_table[index].frequency is not the frequency
>    requested from the hardware. ve_spc_cpufreq_set_rate() will convert
>    from this virtual frequency to an actual frequency, which is then
>    requested from the hardware. For the A7 cluster, the virtual frequency
>    is half the actual frequency. The use of the virtual policy->freq_table
>    frequency results in an incorrect FI scale factor.
> 
>  - max_freq: policy->cpuinfo.max_freq does not correctly identify the
>    maximum frequency of the physical cluster. This value identifies the
>    maximum frequency achievable by the big-LITTLE pair, that is the
>    maximum frequency of the big CPU. But when the LITTLE CPU in the group
>    is used, the hardware maximum frquency passed to arch_set_freq_scale()
>    is incorrect.
> 
>  - missing a scale factor update: when switching clusters, the driver
>    recalculates the frequency of the old clock domain based on the
>    requests of the remaining CPUs in the domain and asks for a clock
>    change. But this does not result in an update in the scale factor.
> 
> Therefore, introduce a local function bLs_set_sched_freq_scale() that
> helps call arch_set_freq_scale() with correct information for the
> is_bL_switching_enabled() case, while maintaining the old, more
> efficient, call site of arch_set_freq_scale() for when cluster
> switching is disabled.
> 
> Also, because of these requirements in computing the scale factor, this
> driver is the only one that maintains custom support for FI, which is
> marked by the presence of the CPUFREQ_CUSTOM_SET_FREQ_SCALE flag.
> 
> [1] https://lwn.net/Articles/481055/
> 
> Signed-off-by: Ionela Voinescu <ionela.voinescu@....com>
> Cc: Viresh Kumar <viresh.kumar@...aro.org>
> Cc: Sudeep Holla <sudeep.holla@....com>
> Cc: Rafael J. Wysocki <rjw@...ysocki.net>
> Cc: Liviu Dudau <liviu.dudau@....com>
> ---
>  drivers/cpufreq/vexpress-spc-cpufreq.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)

Is there anyone who cares for this driver and EAS ? I will just skip doing the
FIE thing here and mark it skipped.

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ