linux-kernel - Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies

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: <6a739b1b-e345-fa09-d815-6e9601aff5f6@arm.com>
Date:   Tue, 13 Oct 2020 14:53:45 +0100
From:   Lukasz Luba <lukasz.luba@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Nicola Mazzucato <nicola.mazzucato@....com>,
        Ionela Voinescu <ionela.voinescu@....com>,
        devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
        vireshk@...nel.org, daniel.lezcano@...aro.org, rjw@...ysocki.net,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        sudeep.holla@....com, chris.redpath@....com,
        morten.rasmussen@....com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for
 cpu-perf-dependencies

Hi Viresh,

On 10/9/20 6:39 AM, Viresh Kumar wrote:

<snip>

> 
> Oh yes, I get it now. Finally. Thanks for helping me out :)
> 
> So if I can say all this stuff in simple terms, this is what it will
> be like:
> 
> - We don't want software aggregation of frequencies and so we need to
>    have per-cpu policies even when they share their clock lines.
> 
> - But we still need a way for other frameworks to know which CPUs
>    share the clock lines (that's what the perf-dependency is all about,
>    right ?).
> 
> - We can't get it from SCMI, but need a DT based solution.
> 
> - Currently for the cpufreq-case we relied for this on the way OPP
>    tables for the CPUs were described. i.e. the opp-table is marked as
>    "shared" and multiple CPUs point to it.

I've started wondering based on the OPP code if this is a good solution.
We would end up with one (?) instance of opp_table and list of devices
pinned to it, in: opp_table->dev_list
It can be seen e.g. in function dev_pm_opp_get_sharing_cpus(),
where we retrieve the cpumask simply looping through the devices:

list_for_each_entry(opp_dev, &opp_table->dev_list, node)
	cpumask_set_cpu(opp_dev->dev->id, cpumask);

This means we have a single OPP table for all pinned CPUs.
I wonder if this is not too strong assumption for still being compliant
with SCMI spec, when in theory performance levels might differ...
(please correct me here it that would never happen)

There is also 2nd function dev_pm_opp_of_get_sharing_cpus() which looks
more promising. But I still don't know if the framework will allow us
to have private OPP tables when we use 'shared' in DT.

Could you clarify if we would get 'private' opp table for each CPU,
which could be then populated independently, but still 2nd function will
work?

Regards,
Lukasz