arm64: Enable max freq invariant scheduler load-tracking and capacity support
authorDietmar Eggemann <dietmar.eggemann@arm.com>
Fri, 25 Sep 2015 16:34:15 +0000 (17:34 +0100)
committerPunit Agrawal <punit.agrawal@arm.com>
Mon, 21 Mar 2016 12:34:30 +0000 (12:34 +0000)
commit51f57a62888f44ef9694660edf408e05dcf7f31e
tree583ccb7bd7fcbca54c7f327c277b39d4c7d41b8d
parent5f21ffcba8f88b503b39040d7c3f45bdb3167ddc
arm64: Enable max freq invariant scheduler load-tracking and capacity support

Maximum Frequency Invariance has to be part of Cpu Invariance because
Frequency Invariance deals only with differences in load-tracking
introduces by Dynamic Frequency Scaling and not with limiting the
possible range of cpu frequency.

By placing Maximum Frequency Invariance into Cpu Invariance,
load-tracking is scaled via arch_scale_cpu_capacity()
in __update_load_avg() and cpu capacity is scaled via
arch_scale_cpu_capacity() in update_cpu_capacity().

To be able to save the extra multiplication in the scheduler hotpath
(__update_load_avg()) we could:

  1 Inform cpufreq about base cpu capacity at boot and let it handle
    scale_cpu_capacity() as well.
  2 Use the cpufreq policy callback which would update a per-cpu current
    cpu_scale and this value would be return in scale_cpu_capacity().
  3 Use per-cpu current max_freq_scale and current cpu_scale with the
    current patch.

Including <linux/cpufreq.h> in topology.h like for the arm arch doesn't
work because of CONFIG_COMPAT=y (Kernel support for 32-bit EL0).
That's why cpufreq_scale_max_freq_capacity() has to be declared extern
in topology.h.

Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
arch/arm64/include/asm/topology.h
arch/arm64/kernel/topology.c