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

Rafael J. Wysocki rafael at kernel.org
Tue Oct 13 07:53:37 EDT 2020


On Tue, Oct 13, 2020 at 12:01 AM Ionela Voinescu
<ionela.voinescu at arm.com> wrote:
>
> Hey Lukasz,
>
> I think after all this discussion (in our own way of describing things)
> we agree on how the current cpufreq based FIE implementation is affected
> in systems that use hardware coordination.
>
> What we don't agree on is the location where that implementation (that
> uses the new mask and aggregation) should be.
>
> On Monday 12 Oct 2020 at 19:19:29 (+0100), Lukasz Luba wrote:
> [..]
> > The previous FIE implementation where arch_set_freq_scale()
> > was called from the drivers, was better suited for this issue.
> > Driver could just use internal dependency cpumask or even
> > do the aggregation to figure out the max freq for cluster
> > if there is a need, before calling arch_set_freq_scale().
> >
> > It is not perfect solution for software FIE, but one of possible
> > when there is no hw counters.
> >
> [..]
>
> > Difference between new FIE and old FIE (from v5.8) is that the new one
> > purely relies on schedutil max freq value (which will now be missing),
> > while the old FIE was called by the driver and thus it was an option to
> > fix only the affected cpufreq driver [1][2].
> >
>
> My final argument is that now you have 2 drivers that would need this
> support, next you'll have 3 (the new mediatek driver), and in the future
> there will be more. So why limit and duplicate this functionality in the
> drivers? Why not make it generic for all drivers to use if the system
> is using hardware coordination?
>
> Additionally, I don't think drivers should not even need to know about
> these dependency/clock domains. They should act at the level of the
> policy, which in this case will be at the level of each CPU.

The policies come from the driver, though.

The driver decides how many CPUs will be there in a policy and how to
handle them at the initialization time.

The core has no idea whether or not there is HW coordination in the
system, the driver is expected to know that and take that into
account.

Accordingly, it looks like there should be an option for drivers to
arrange things in the most convenient way (from their perspective) and
that option has gone away now.



More information about the linux-arm-kernel mailing list