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> |
||
---|---|---|
.. | ||
alpha | ||
arc | ||
arm | ||
arm64 | ||
avr32 | ||
blackfin | ||
c6x | ||
cris | ||
frv | ||
h8300 | ||
hexagon | ||
ia64 | ||
m32r | ||
m68k | ||
metag | ||
microblaze | ||
mips | ||
mn10300 | ||
nios2 | ||
openrisc | ||
parisc | ||
powerpc | ||
s390 | ||
score | ||
sh | ||
sparc | ||
tile | ||
um | ||
unicore32 | ||
x86 | ||
xtensa | ||
.gitignore | ||
Kconfig |