On 29 April 2015 at 14:22, Daniel Lezcano daniel.lezcano@linaro.org wrote:
On 04/29/2015 01:15 PM, Vincent Guittot wrote:
On 29 April 2015 at 12:34, Daniel Lezcano daniel.lezcano@linaro.org wrote:
On 04/27/2015 09:46 AM, Michael Turquette wrote:
From: Morten Rasmussen Morten.Rasmussen@arm.com
Implements arch-specific function to provide the scheduler with a frequency scaling correction factor for more accurate load-tracking. The factor is:
current_freq(cpu) << SCHED_CAPACITY_SHIFT / max_freq(cpu)
This implementation only provides frequency invariance. No micro-architecture invariance yet.
Signed-off-by: Morten Rasmussen morten.rasmussen@arm.com
changes since internal v1:
replaced two commits from eas v3 with this new one from Morten
arch/arm/include/asm/topology.h | 7 ++++++ arch/arm/kernel/smp.c | 53
+++++++++++++++++++++++++++++++++++++++-- arch/arm/kernel/topology.c | 17 +++++++++++++ 3 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h index 2fe85ff..4b985dc 100644 --- a/arch/arm/include/asm/topology.h +++ b/arch/arm/include/asm/topology.h @@ -24,6 +24,13 @@ void init_cpu_topology(void); void store_cpu_topology(unsigned int cpuid); const struct cpumask *cpu_coregroup_mask(int cpu);
+#define arch_scale_freq_capacity arm_arch_scale_freq_capacity
What is for this macro ?
This is used to doesn't add any useless computation in the hot path when arch_scale_freq_capacity is not used. This has been asked by peter
What is the difference with having a dummy empty function with a 'weak' attribute (which is how it is done currently in the kernel) ?
You can have a look at the thread for the full discussion: https://lkml.org/lkml/2015/3/24/113
+struct sched_domain; +extern +unsigned long arm_arch_scale_freq_capacity(struct sched_domain *sd, int cpu);
+DECLARE_PER_CPU(atomic_long_t, cpu_freq_capacity);
IMO cpu_freq_capacity should be statically declared in the core code and modified/inspected through accessors also in the core code.
eg.
sched_cpu_freq_capacity_set(int cpu, unsigned long freq_capacity); unsigned long sched_cpu_freq_capacity_get(int cpu);
Peter asked that arm_arch_scale_freq_capacity should not add any additional instruction if not used by an arch because it's on the very hot path of the scheduler
#else
static inline void init_cpu_topology(void) { } diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 86ef244..297ce1b 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -672,12 +672,34 @@ static DEFINE_PER_CPU(unsigned long, l_p_j_ref); static DEFINE_PER_CPU(unsigned long, l_p_j_ref_freq); static unsigned long global_l_p_j_ref; static unsigned long global_l_p_j_ref_freq; +static DEFINE_PER_CPU(atomic_long_t, cpu_max_freq);
In the code cpu_max_freq is used to update the scale freq invariance.
Wouldn't be simpler to use directly: cpufreq_quick_get_max(int cpu) instead of declaring another per cpu variable ?
+DEFINE_PER_CPU(atomic_long_t, cpu_freq_capacity);
+/*
- Scheduler load-tracking scale-invariance
- Provides the scheduler with a scale-invariance correction factor
that
- compensates for frequency scaling through arch_scale_freq_capacity()
- (implemented in topology.c).
- */
+static inline +void scale_freq_capacity(int cpu, unsigned long curr, unsigned long max) +{
unsigned long capacity;
if (!max)
return;
capacity = (curr << SCHED_CAPACITY_SHIFT) / max;
atomic_long_set(&per_cpu(cpu_freq_capacity, cpu), capacity);
+}
static int cpufreq_callback(struct notifier_block *nb, unsigned long val, void *data) { struct cpufreq_freqs *freq = data; int cpu = freq->cpu;
unsigned long max = atomic_long_read(&per_cpu(cpu_max_freq,
cpu));
if (freq->flags & CPUFREQ_CONST_LOOPS) return NOTIFY_OK;
@@ -702,6 +724,9 @@ static int cpufreq_callback(struct notifier_block *nb, per_cpu(l_p_j_ref_freq, cpu), freq->new); }
scale_freq_capacity(cpu, freq->new, max);
scale_freq_capacity(cpu, cpufreq_quick_get_max(cpu)) ?
}return NOTIFY_OK;
@@ -709,11 +734,35 @@ static struct notifier_block cpufreq_notifier = { .notifier_call = cpufreq_callback, };
+static int cpufreq_policy_callback(struct notifier_block *nb,
unsigned long val, void
*data) +{
struct cpufreq_policy *policy = data;
int i;
for_each_cpu(i, policy->cpus) {
scale_freq_capacity(i, policy->cur, policy->max);
scale_freq_capacity(cpu, cpufreq_quick_get_max(cpu)) ?
atomic_long_set(&per_cpu(cpu_max_freq, i), policy->max);
atomic_long_set no longer needed.
}
return NOTIFY_OK;
+}
+static struct notifier_block cpufreq_policy_notifier = {
.notifier_call = cpufreq_policy_callback,
+};
- static int __init register_cpufreq_notifier(void) {
return cpufreq_register_notifier(&cpufreq_notifier,
int ret;
ret = cpufreq_register_notifier(&cpufreq_notifier,
CPUFREQ_TRANSITION_NOTIFIER);
if (ret)
return ret;
return cpufreq_register_notifier(&cpufreq_policy_notifier,
CPUFREQ_POLICY_NOTIFIER); } core_initcall(register_cpufreq_notifier);
- #endif
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index 08b7847..9c09e6e 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -169,6 +169,23 @@ static void update_cpu_capacity(unsigned int cpu) cpu, arch_scale_cpu_capacity(NULL, cpu)); }
+/*
- Scheduler load-tracking scale-invariance
- Provides the scheduler with a scale-invariance correction factor
that
- compensates for frequency scaling (arch_scale_freq_capacity()). The
scaling
- factor is updated in smp.c
- */
+unsigned long arm_arch_scale_freq_capacity(struct sched_domain *sd, int cpu) +{
unsigned long curr =
atomic_long_read(&per_cpu(cpu_freq_capacity, cpu));
if (!curr)
return SCHED_CAPACITY_SCALE;
Why not initialized 'cpu_freq_capacity' with the right value, so !curr won't happen ?
return curr;
+}
I wonder if you should better move arm_arch_scale_freq_capacity in the arch/arm/kernel/smp.c as all other fucntion and variable are there. This will allow you to remove DECLARE_PER_CPU(atomic_long_t, cpu_freq_capacity); form the topology.h file
- #else static inline void parse_dt_topology(void) {} static inline void update_cpu_capacity(unsigned int cpuid) {}
-- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
-- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog