Hi Viresh,
On 11/6/20 9:20 AM, Viresh Kumar wrote:
On 02-11-20, 12:01, Nicola Mazzucato wrote:
This is a continuation of the previous v2, where we focused mostly on the
dt binding.
I am seeking some feedback/comments on the following two approaches.
Intro:
We have seen that in a system where performance control and hardware
description do not match (i.e. per-cpu), we still need the information of
how the v/f lines are shared among the cpus. We call this information
"performance dependencies".
We got this info through the opp-shared (the previous 2 patches aim for
that).
Problem:
How do we share such info (retrieved from a cpufreq driver) to other
consumers that rely on it? I have two proposals.
I haven't really stop thinking about what and how we should solve
this, but I have few concerns first.
2) drivers/thermal/cpufreq_cooling: Replace related_cpus with dependent_cpus
I am not sure if I understand completely on how this is going to be
modified/work.
The only use of related_cpus in the cooling driver is in the helper
cdev->get_requested_power(), where we need to find the total power
being consumed by devices controlled by the cooling device. Right ?
Now the cooling devices today are very closely related to the cpufreq
policy, the registration function itself takes a cpufreq policy as an
argument.
Consider that you have an octa-core platform and all the CPUs are
dependent on each other. With your suggested changes and hw control,
we will have different cpufreq policies for each CPU. And so we will
have a cooling device, cdev, for each CPU as well. When the IPA
governor calls cdev->get_requested_power(), why should we ever bother
to traverse the list of dependent_cpus and not related_cpus only ?
Otherwise the same CPU will have its load contributed to the power of
8 cooling devices.
Good question.
How about a different interface for those cpufreq drivers?
That new registration API would allow to specify the cpumask.
Or rely on EM cpumask: em_span_cpus(em)
Currently we have two ways to register cooling device:
1. when the cpufreq driver set a flag CPUFREQ_IS_COOLING_DEV, the core
will register cooling device
2. cpufreq driver can explicitly call the registration function:
cpufreq_cooling_register() with 'policy' as argument
That would need substantial change to the cpufreq cooling code, from
policy oriented to custom driver's cpumask (like EM registration).
Regards,
Lukasz
