summaryrefslogtreecommitdiff
path: root/kernel/sysctl_binary.c
diff options
context:
space:
mode:
authorDietmar Eggemann <dietmar.eggemann@arm.com>2015-09-25 17:34:15 +0100
committerAmit Pundir <amit.pundir@linaro.org>2016-09-14 14:48:50 +0530
commit81ca8262ce7ba30a17f1843acff934a1a380a1ca (patch)
treeef3b4833b1f00da232a34f39868430eb0ddaf61d /kernel/sysctl_binary.c
parentf610f202d3e4f326a357c1796954bf7a0cbfbe7e (diff)
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>
Diffstat (limited to 'kernel/sysctl_binary.c')
0 files changed, 0 insertions, 0 deletions