On 21/06/17 01:31, Saravana Kannan wrote:

On 06/19/2017 11:17 PM, Viresh Kumar wrote:

quoted

On Thu, Jun 8, 2017 at 1:25 PM, Dietmar Eggemann
[off-list ref] wrote:

quoted

diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c

quoted

  static int __init register_cpufreq_notifier(void)
  {
+       int ret;
+
         /*
          * on ACPI-based systems we need to use the default cpu
capacity
          * until we have the necessary code to parse the cpu
capacity, so

@@ -225,8 +265,14 @@ static int __init register_cpufreq_notifier(void)

         cpumask_copy(cpus_to_visit, cpu_possible_mask);

-       return cpufreq_register_notifier(&init_cpu_capacity_notifier,
-                                        CPUFREQ_POLICY_NOTIFIER);
+       ret = cpufreq_register_notifier(&init_cpu_capacity_notifier,
+                                       CPUFREQ_POLICY_NOTIFIER);

Wanted to make sure that we all understand the constraints this is
going to add
for the ARM64 platforms.

With the introduction of this transition notifier, we would not be
able to use
the fast-switch path in the schedutil governor. I am not sure if there
are any
ARM platforms that can actually use the fast-switch path in future or not
though. The requirement of fast-switch path is that the freq can be
changed
without sleeping in the hot-path.

So, will we ever want fast-switching for ARM platforms ?

I don't think we should go down a path that'll prevent ARM platform from
switching over to fast-switching in the future.

Understood. But IMHO implementing a cpufreq transition notifier based
Frequency Invariance Engine (FIE) which provides frequency-invariant
accounting for 100% of today's arm/arm64 system is legitimate.

Like I said in the other email in this thread today, I can make sure
that I only register the cpufreq transition notifier if none of the
policies support fast frequency switching. In this case people can use
mainline to experiment with cpufreq drivers supporting fast frequency
switching (without FIE support).

Having said that, I'm not sure I fully agree with the decision to
completely disable notifiers in the fast-switching case. How many of the
current users of notifiers truly need support for sleeping in the
notifier? Why not make all the transition notifiers atomic? Or at least
add atomic transition notifiers that can be registered for separately if
the client doesn't need the ability to sleep?

IMHO, that's a different construction side inside the cpufreq framework.
Patches which introduced the fast frequency switching support in cpufreq
clearly state that "... fast frequency switching is inherently
incompatible with cpufreq transition notifiers ...".

If we can get rid of this restriction, the cpufreq transition notifier
based FIE implementation could stay. Otherwise we need a FIE for systems
with fast frequency switching based on something else, e.g. performance
counters.

Most of the clients don't seem like ones that'll need to sleep.

There are a bunch of generic off-tree drivers (can't upstream them yet
because it depends on the bus scaling framework) that also depend on
CPUfreq transition notifiers that are going to stop working if fast
switching becomes available in the future. So, this decision to disallow
transition notifiers is painful for other reasons too.

Falls into the same bucket for me ... you have a requirement against the
cpufreq framework to let cpufreq transition notifier work for fast
frequency switching drivers.

[...]