This patchset creates an arch_scale_freq_power function for ARM, which is used to set the relative capacity of each core of a big.LITTLE system. It also removes the broken power estimation of x86.
Modification since v3: - Add comments - Add optimization for SMP system - Ensure that capacity of a CPU will be at most 1
Modification since v2: - set_power_scale function becomes static - Rework loop in update_siblings_masks - Remove useless code in parse_dt_topology
Modification since v1: - Add and update explanation about the use of the table and the range of the value - Remove the use of NR_CPUS and use nr_cpu_ids instead - Remove broken power estimation of x86
Peter Zijlstra (1): sched, x86: Remove broken power estimation
Vincent Guittot (4): ARM: topology: Add arch_scale_freq_power function ARM: topology: factorize the update of sibling masks ARM: topology: Update cpu_power according to DT information sched: cpu_power: enable ARCH_POWER
arch/arm/kernel/topology.c | 239 ++++++++++++++++++++++++++++++++++++++---- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/sched.c | 55 ---------- kernel/sched/features.h | 2 +- 4 files changed, 219 insertions(+), 79 deletions(-) delete mode 100644 arch/x86/kernel/cpu/sched.c
Add infrastructure to be able to modify the cpu_power of each core
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org --- arch/arm/kernel/topology.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index 8200dea..51f23b3 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -22,6 +22,37 @@ #include <asm/cputype.h> #include <asm/topology.h>
+/* + * cpu power scale management + */ + +/* + * cpu power table + * This per cpu data structure describes the relative capacity of each core. + * On a heteregenous system, cores don't have the same computation capacity + * and we reflect that difference in the cpu_power field so the scheduler can + * take this difference into account during load balance. A per cpu structure + * is preferred because each CPU updates its own cpu_power field during the + * load balance except for idle cores. One idle core is selected to run the + * rebalance_domains for all idle cores and the cpu_power can be updated + * during this sequence. + */ +static DEFINE_PER_CPU(unsigned long, cpu_scale); + +unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu) +{ + return per_cpu(cpu_scale, cpu); +} + +static void set_power_scale(unsigned int cpu, unsigned long power) +{ + per_cpu(cpu_scale, cpu) = power; +} + +/* + * cpu topology management + */ + #define MPIDR_SMP_BITMASK (0x3 << 30) #define MPIDR_SMP_VALUE (0x2 << 30)
@@ -41,6 +72,9 @@ #define MPIDR_LEVEL2_MASK 0xFF #define MPIDR_LEVEL2_SHIFT 16
+/* + * cpu topology table + */ struct cputopo_arm cpu_topology[NR_CPUS];
const struct cpumask *cpu_coregroup_mask(int cpu) @@ -134,7 +168,7 @@ void init_cpu_topology(void) { unsigned int cpu;
- /* init core mask */ + /* init core mask and power*/ for_each_possible_cpu(cpu) { struct cputopo_arm *cpu_topo = &(cpu_topology[cpu]);
@@ -143,6 +177,8 @@ void init_cpu_topology(void) cpu_topo->socket_id = -1; cpumask_clear(&cpu_topo->core_sibling); cpumask_clear(&cpu_topo->thread_sibling); + + set_power_scale(cpu, SCHED_POWER_SCALE); } smp_wmb(); }
This factorization has also been proposed in another patch that has not been merged yet: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht... So, this patch could be dropped depending of the state of the other one.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieralisi@arm.com Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org --- arch/arm/kernel/topology.c | 48 +++++++++++++++++++++++++------------------- 1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index 51f23b3..eb5fc81 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -82,6 +82,32 @@ const struct cpumask *cpu_coregroup_mask(int cpu) return &cpu_topology[cpu].core_sibling; }
+void update_siblings_masks(unsigned int cpuid) +{ + struct cputopo_arm *cpu_topo, *cpuid_topo = &cpu_topology[cpuid]; + int cpu; + + /* update core and thread sibling masks */ + for_each_possible_cpu(cpu) { + cpu_topo = &cpu_topology[cpu]; + + if (cpuid_topo->socket_id != cpu_topo->socket_id) + continue; + + cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); + if (cpu != cpuid) + cpumask_set_cpu(cpu, &cpuid_topo->core_sibling); + + if (cpuid_topo->core_id != cpu_topo->core_id) + continue; + + cpumask_set_cpu(cpuid, &cpu_topo->thread_sibling); + if (cpu != cpuid) + cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling); + } + smp_wmb(); +} + /* * store_cpu_topology is called at boot when only one cpu is running * and with the mutex cpu_hotplug.lock locked, when several cpus have booted, @@ -91,7 +117,6 @@ void store_cpu_topology(unsigned int cpuid) { struct cputopo_arm *cpuid_topo = &cpu_topology[cpuid]; unsigned int mpidr; - unsigned int cpu;
/* If the cpu topology has been already set, just return */ if (cpuid_topo->core_id != -1) @@ -133,26 +158,7 @@ void store_cpu_topology(unsigned int cpuid) cpuid_topo->socket_id = -1; }
- /* update core and thread sibling masks */ - for_each_possible_cpu(cpu) { - struct cputopo_arm *cpu_topo = &cpu_topology[cpu]; - - if (cpuid_topo->socket_id == cpu_topo->socket_id) { - cpumask_set_cpu(cpuid, &cpu_topo->core_sibling); - if (cpu != cpuid) - cpumask_set_cpu(cpu, - &cpuid_topo->core_sibling); - - if (cpuid_topo->core_id == cpu_topo->core_id) { - cpumask_set_cpu(cpuid, - &cpu_topo->thread_sibling); - if (cpu != cpuid) - cpumask_set_cpu(cpu, - &cpuid_topo->thread_sibling); - } - } - } - smp_wmb(); + update_siblings_masks(cpuid);
printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n", cpuid, cpu_topology[cpuid].thread_id,
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org --- arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index eb5fc81..198b084 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -17,7 +17,9 @@ #include <linux/percpu.h> #include <linux/node.h> #include <linux/nodemask.h> +#include <linux/of.h> #include <linux/sched.h> +#include <linux/slab.h>
#include <asm/cputype.h> #include <asm/topology.h> @@ -49,6 +51,152 @@ static void set_power_scale(unsigned int cpu, unsigned long power) per_cpu(cpu_scale, cpu) = power; }
+#ifdef CONFIG_OF +struct cpu_efficiency { + const char *compatible; + unsigned long efficiency; +}; + +/* + * Table of relative efficiency of each processors + * The efficiency value must fit in 20bit and the final + * cpu_scale value must be in the range + * 0 < cpu_scale < 3*SCHED_POWER_SCALE/2 + * in order to return at most 1 when DIV_ROUND_CLOSEST + * is used to compute the capacity of a CPU. + * Processors that are not defined in the table, + * use the default SCHED_POWER_SCALE value for cpu_scale. + */ +struct cpu_efficiency table_efficiency[] = { + {"arm,cortex-a15", 3891}, + {"arm,cortex-a7", 2048}, + {NULL, }, +}; + +struct cpu_capacity { + unsigned long hwid; + unsigned long capacity; +}; + +struct cpu_capacity *cpu_capacity; + +unsigned long middle_capacity = 1; + +/* + * Iterate all CPUs' descriptor in DT and compute the efficiency + * (as per table_efficiency). Also calculate a middle efficiency + * as close as possible to (max{eff_i} - min{eff_i}) / 2 + * This is later used to scale the cpu_power field such that an + * 'average' CPU is of middle power. Also see the comments near + * table_efficiency[] and update_cpu_power(). + */ +static void __init parse_dt_topology(void) +{ + struct cpu_efficiency *cpu_eff; + struct device_node *cn = NULL; + unsigned long min_capacity = (unsigned long)(-1); + unsigned long max_capacity = 0; + unsigned long capacity = 0; + int alloc_size, cpu = 0; + + alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity); + cpu_capacity = (struct cpu_capacity *)kzalloc(alloc_size, GFP_NOWAIT); + + while ((cn = of_find_node_by_type(cn, "cpu"))) { + const u32 *rate, *reg; + int len; + + if (cpu >= num_possible_cpus()) + break; + + for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++) + if (of_device_is_compatible(cn, cpu_eff->compatible)) + break; + + if (cpu_eff->compatible == NULL) + continue; + + rate = of_get_property(cn, "clock-frequency", &len); + if (!rate || len != 4) { + pr_err("%s missing clock-frequency property\n", + cn->full_name); + continue; + } + + reg = of_get_property(cn, "reg", &len); + if (!reg || len != 4) { + pr_err("%s missing reg property\n", cn->full_name); + continue; + } + + capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency; + + /* Save min capacity of the system */ + if (capacity < min_capacity) + min_capacity = capacity; + + /* Save max capacity of the system */ + if (capacity > max_capacity) + max_capacity = capacity; + + cpu_capacity[cpu].capacity = capacity; + cpu_capacity[cpu++].hwid = be32_to_cpup(reg); + } + + if (cpu < num_possible_cpus()) + cpu_capacity[cpu].hwid = (unsigned long)(-1); + + /* If min and max capacities are equals, we bypass the update of the + * cpu_scale because all CPUs have the same capacity. Otherwise, we + * compute a middle_capacity factor that will ensure that the capacity + * of an 'average' CPU of the system will be as close as possible to + * SCHED_POWER_SCALE, which is the default value, but with the + * constraint explained near table_efficiency[]. + */ + if (min_capacity == max_capacity) + cpu_capacity[0].hwid = (unsigned long)(-1); + else if (4*max_capacity < (3*(max_capacity + min_capacity))) + middle_capacity = (min_capacity + max_capacity) + >> (SCHED_POWER_SHIFT+1); + else + middle_capacity = ((max_capacity / 3) + >> (SCHED_POWER_SHIFT-1)) + 1; + +} + +/* + * Look for a customed capacity of a CPU in the cpu_capacity table during the + * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the + * function returns directly for SMP system. + */ +void update_cpu_power(unsigned int cpu, unsigned long hwid) +{ + unsigned int idx = 0; + + /* look for the cpu's hwid in the cpu capacity table */ + for (idx = 0; idx < num_possible_cpus(); idx++) { + if (cpu_capacity[idx].hwid == hwid) + break; + + if (cpu_capacity[idx].hwid == -1) + return; + } + + if (idx == num_possible_cpus()) + return; + + set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity); + + printk(KERN_INFO "CPU%u: update cpu_power %lu\n", + cpu, arch_scale_freq_power(NULL, cpu)); +} + +#else +static inline void parse_dt_topology(void) {} +static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {} +#endif + + /* * cpu topology management */ @@ -62,6 +210,7 @@ static void set_power_scale(unsigned int cpu, unsigned long power) * These masks reflect the current use of the affinity levels. * The affinity level can be up to 16 bits according to ARM ARM */ +#define MPIDR_HWID_BITMASK 0xFFFFFF
#define MPIDR_LEVEL0_MASK 0x3 #define MPIDR_LEVEL0_SHIFT 0 @@ -160,6 +309,8 @@ void store_cpu_topology(unsigned int cpuid)
update_siblings_masks(cpuid);
+ update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK); + printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n", cpuid, cpu_topology[cpuid].thread_id, cpu_topology[cpuid].core_id, @@ -187,4 +338,6 @@ void init_cpu_topology(void) set_power_scale(cpu, SCHED_POWER_SCALE); } smp_wmb(); + + parse_dt_topology(); }
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Regards Santosh
On Mon, 2012-07-09 at 16:25 +0530, Shilimkar, Santosh wrote:
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Good incentive to get there though.. :-)
On Mon, Jul 9, 2012 at 4:30 PM, Peter Zijlstra a.p.zijlstra@chello.nl wrote:
On Mon, 2012-07-09 at 16:25 +0530, Shilimkar, Santosh wrote:
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Good incentive to get there though.. :-)
Sure and I guess thats the thought process from Vincent too :-)
Regards Santosh
On 9 July 2012 12:55, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
Hi Santosh,
I had thought of adding such additional way to set cpu_power of big.LITTLE but my conclusion was -it's a new platform so it should come with DT -DT is already required by other patches linked to big.LITTLE (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht...) -There is no device that can be easily used to get such information at this early boot stage.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Can't you support both type of devices on your platform ? You can move your device to DT mode when it is supported ?
Regards, Vincent
Regards Santosh
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 12:55, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
Hi Santosh,
I had thought of adding such additional way to set cpu_power of big.LITTLE but my conclusion was -it's a new platform so it should come with DT -DT is already required by other patches linked to big.LITTLE (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht...) -There is no device that can be easily used to get such information at this early boot stage.
I see. Its new processor but it is just 1 one of the IP in an entire SOC. As mentioned below I was talking about full SOC support including all the driver subsystem with DT.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Can't you support both type of devices on your platform ? You can move your device to DT mode when it is supported ?
That is what eventually people end up doing who don't have DT ready for entire SOC. I was trying to ask whether at least some method is proposed(need not be merged in mainline) to have the big.LITTLE information parsing without DT.
Regards Santosh
On 9 July 2012 15:00, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 12:55, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
Hi Santosh,
I had thought of adding such additional way to set cpu_power of big.LITTLE but my conclusion was -it's a new platform so it should come with DT -DT is already required by other patches linked to big.LITTLE (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht...) -There is no device that can be easily used to get such information at this early boot stage.
I see. Its new processor but it is just 1 one of the IP in an entire SOC. As mentioned below I was talking about full SOC support including all the driver subsystem with DT.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Can't you support both type of devices on your platform ? You can move your device to DT mode when it is supported ?
That is what eventually people end up doing who don't have DT ready for entire SOC. I was trying to ask whether at least some method is proposed(need not be merged in mainline) to have the big.LITTLE information parsing without DT.
Ok, IIUC, you need a temporary methods, which doesn't need to be merged in mainline, to set the cpu_scale field ?
Regards Santosh
On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 15:00, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 12:55, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
Hi Santosh,
I had thought of adding such additional way to set cpu_power of big.LITTLE but my conclusion was -it's a new platform so it should come with DT -DT is already required by other patches linked to big.LITTLE (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht...) -There is no device that can be easily used to get such information at this early boot stage.
I see. Its new processor but it is just 1 one of the IP in an entire SOC. As mentioned below I was talking about full SOC support including all the driver subsystem with DT.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Can't you support both type of devices on your platform ? You can move your device to DT mode when it is supported ?
That is what eventually people end up doing who don't have DT ready for entire SOC. I was trying to ask whether at least some method is proposed(need not be merged in mainline) to have the big.LITTLE information parsing without DT.
Ok, IIUC, you need a temporary methods, which doesn't need to be merged in mainline, to set the cpu_scale field ?
Yep.
Regards Santosh
On 9 July 2012 16:37, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 15:00, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 12:55, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
Hi Santosh,
I had thought of adding such additional way to set cpu_power of big.LITTLE but my conclusion was -it's a new platform so it should come with DT -DT is already required by other patches linked to big.LITTLE (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht...) -There is no device that can be easily used to get such information at this early boot stage.
I see. Its new processor but it is just 1 one of the IP in an entire SOC. As mentioned below I was talking about full SOC support including all the driver subsystem with DT.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Can't you support both type of devices on your platform ? You can move your device to DT mode when it is supported ?
That is what eventually people end up doing who don't have DT ready for entire SOC. I was trying to ask whether at least some method is proposed(need not be merged in mainline) to have the big.LITTLE information parsing without DT.
Ok, IIUC, you need a temporary methods, which doesn't need to be merged in mainline, to set the cpu_scale field ?
Yep.
You could use set_power_scale in your platform code to set the cpu_power of your CPUs until DT is ready for your platform.
Regards, Vincent
Regards Santosh
On Mon, Jul 9, 2012 at 8:40 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 16:37, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
On Mon, Jul 9, 2012 at 8:06 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 15:00, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
On Mon, Jul 9, 2012 at 6:02 PM, Vincent Guittot vincent.guittot@linaro.org wrote:
On 9 July 2012 12:55, Shilimkar, Santosh santosh.shilimkar@ti.com wrote:
Vincent, On Mon, Jul 9, 2012 at 2:57 PM, Vincent Guittot vincent.guittot@linaro.org wrote: > Use cpu compatibility field and clock-frequency field of DT to > estimate the capacity of each core of the system and to update > the cpu_power field accordingly. > This patch enables to put more running tasks on big cores than > on LITTLE ones. But this patch doesn't ensure that long running > tasks will run on big cores and short ones on LITTLE cores. > > Signed-off-by: Vincent Guittot vincent.guittot@linaro.org > Reviewed-by: Namhyung Kim namhyung@kernel.org > --- > arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 153 insertions(+) > Sorry for not giving this comment on previous version but we should also have a way to provide the big.LITTLE information without Device Tree. May be a platform device/data.
Hi Santosh,
I had thought of adding such additional way to set cpu_power of big.LITTLE but my conclusion was -it's a new platform so it should come with DT -DT is already required by other patches linked to big.LITTLE (http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.ht...) -There is no device that can be easily used to get such information at this early boot stage.
I see. Its new processor but it is just 1 one of the IP in an entire SOC. As mentioned below I was talking about full SOC support including all the driver subsystem with DT.
I know we are moving DT way, but remember apart from core kernel infrastructure, to have a complete product build with DT means all the drivers must be already supporting DT which is not the case with many huge driver sub-systems like USB, display subsystem, Audio etc.
Having that support would greatly help for the SOC's which have not yet reached to stage where entire SOC is DT compliant and want to use big.LITTLE infrastructure.
Can't you support both type of devices on your platform ? You can move your device to DT mode when it is supported ?
That is what eventually people end up doing who don't have DT ready for entire SOC. I was trying to ask whether at least some method is proposed(need not be merged in mainline) to have the big.LITTLE information parsing without DT.
Ok, IIUC, you need a temporary methods, which doesn't need to be merged in mainline, to set the cpu_scale field ?
Yep.
You could use set_power_scale in your platform code to set the cpu_power of your CPUs until DT is ready for your platform.
Thanks for the clarification. Will try that out.
Regards Santosh
On Mon, Jul 09, 2012 at 11:27:04AM +0200, Vincent Guittot wrote:
Use cpu compatibility field and clock-frequency field of DT to estimate the capacity of each core of the system and to update the cpu_power field accordingly. This patch enables to put more running tasks on big cores than on LITTLE ones. But this patch doesn't ensure that long running tasks will run on big cores and short ones on LITTLE cores.
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org Reviewed-by: Namhyung Kim namhyung@kernel.org
arch/arm/kernel/topology.c | 153 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index eb5fc81..198b084 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -17,7 +17,9 @@ #include <linux/percpu.h> #include <linux/node.h> #include <linux/nodemask.h> +#include <linux/of.h> #include <linux/sched.h> +#include <linux/slab.h> #include <asm/cputype.h> #include <asm/topology.h> @@ -49,6 +51,152 @@ static void set_power_scale(unsigned int cpu, unsigned long power) per_cpu(cpu_scale, cpu) = power; } +#ifdef CONFIG_OF +struct cpu_efficiency {
- const char *compatible;
- unsigned long efficiency;
+};
+/*
- Table of relative efficiency of each processors
- The efficiency value must fit in 20bit and the final
- cpu_scale value must be in the range
- 0 < cpu_scale < 3*SCHED_POWER_SCALE/2
- in order to return at most 1 when DIV_ROUND_CLOSEST
- is used to compute the capacity of a CPU.
- Processors that are not defined in the table,
- use the default SCHED_POWER_SCALE value for cpu_scale.
- */
+struct cpu_efficiency table_efficiency[] = {
- {"arm,cortex-a15", 3891},
- {"arm,cortex-a7", 2048},
- {NULL, },
How accurate would we expect this to be, in general?
How the SoC is integrated will affect things, and throughput is not a linear function of the clock frequency due to bus and DRAM timing effects, and so on.
Part of the issue here is that two CPUs can be "compatible" in the DT sense even when in performance terms there may be significant differences (different integration options, difference cache sizes, etc.)
If the CPU power estimate doesn't need to be very precise (I suspect it doesn't?) then then may not be a problem.
Otherwise, could it make sense to put values into the DT itself, or at least to have the possibility of doing so?
Of course, this can probably be delayed until it proves to be necessary. Maybe we'll never need it.
Cheers ---Dave
+};
+struct cpu_capacity {
- unsigned long hwid;
- unsigned long capacity;
+};
+struct cpu_capacity *cpu_capacity;
+unsigned long middle_capacity = 1;
+/*
- Iterate all CPUs' descriptor in DT and compute the efficiency
- (as per table_efficiency). Also calculate a middle efficiency
- as close as possible to (max{eff_i} - min{eff_i}) / 2
- This is later used to scale the cpu_power field such that an
- 'average' CPU is of middle power. Also see the comments near
- table_efficiency[] and update_cpu_power().
- */
+static void __init parse_dt_topology(void) +{
- struct cpu_efficiency *cpu_eff;
- struct device_node *cn = NULL;
- unsigned long min_capacity = (unsigned long)(-1);
- unsigned long max_capacity = 0;
- unsigned long capacity = 0;
- int alloc_size, cpu = 0;
- alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
- cpu_capacity = (struct cpu_capacity *)kzalloc(alloc_size, GFP_NOWAIT);
- while ((cn = of_find_node_by_type(cn, "cpu"))) {
const u32 *rate, *reg;int len;if (cpu >= num_possible_cpus())break;for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)if (of_device_is_compatible(cn, cpu_eff->compatible))break;if (cpu_eff->compatible == NULL)continue;rate = of_get_property(cn, "clock-frequency", &len);if (!rate || len != 4) {pr_err("%s missing clock-frequency property\n",cn->full_name);continue;}reg = of_get_property(cn, "reg", &len);if (!reg || len != 4) {pr_err("%s missing reg property\n", cn->full_name);continue;}capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;/* Save min capacity of the system */if (capacity < min_capacity)min_capacity = capacity;/* Save max capacity of the system */if (capacity > max_capacity)max_capacity = capacity;cpu_capacity[cpu].capacity = capacity;cpu_capacity[cpu++].hwid = be32_to_cpup(reg);- }
- if (cpu < num_possible_cpus())
cpu_capacity[cpu].hwid = (unsigned long)(-1);- /* If min and max capacities are equals, we bypass the update of the
* cpu_scale because all CPUs have the same capacity. Otherwise, we* compute a middle_capacity factor that will ensure that the capacity* of an 'average' CPU of the system will be as close as possible to* SCHED_POWER_SCALE, which is the default value, but with the* constraint explained near table_efficiency[].*/- if (min_capacity == max_capacity)
cpu_capacity[0].hwid = (unsigned long)(-1);- else if (4*max_capacity < (3*(max_capacity + min_capacity)))
middle_capacity = (min_capacity + max_capacity)>> (SCHED_POWER_SHIFT+1);- else
middle_capacity = ((max_capacity / 3)>> (SCHED_POWER_SHIFT-1)) + 1;+}
+/*
- Look for a customed capacity of a CPU in the cpu_capacity table during the
- boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
- function returns directly for SMP system.
- */
+void update_cpu_power(unsigned int cpu, unsigned long hwid) +{
- unsigned int idx = 0;
- /* look for the cpu's hwid in the cpu capacity table */
- for (idx = 0; idx < num_possible_cpus(); idx++) {
if (cpu_capacity[idx].hwid == hwid)break;if (cpu_capacity[idx].hwid == -1)return;- }
- if (idx == num_possible_cpus())
return;- set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
- printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
cpu, arch_scale_freq_power(NULL, cpu));+}
+#else +static inline void parse_dt_topology(void) {} +static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {} +#endif
/*
- cpu topology management
*/ @@ -62,6 +210,7 @@ static void set_power_scale(unsigned int cpu, unsigned long power)
- These masks reflect the current use of the affinity levels.
- The affinity level can be up to 16 bits according to ARM ARM
*/ +#define MPIDR_HWID_BITMASK 0xFFFFFF #define MPIDR_LEVEL0_MASK 0x3 #define MPIDR_LEVEL0_SHIFT 0 @@ -160,6 +309,8 @@ void store_cpu_topology(unsigned int cpuid) update_siblings_masks(cpuid);
- update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
- printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n", cpuid, cpu_topology[cpuid].thread_id, cpu_topology[cpuid].core_id,
@@ -187,4 +338,6 @@ void init_cpu_topology(void) set_power_scale(cpu, SCHED_POWER_SCALE); } smp_wmb();
- parse_dt_topology();
}
1.7.9.5
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
From: Peter Zijlstra a.p.zijlstra@chello.nl
The x86 sched power implementation has been broken forever and gets in the way of other stuff, remove it.
For archaeological interest, fixing this code would require dealing with the cross-cpu calling of these functions and more importantly, we need to filter idle time out of the a/m-perf stuff because the ratio will go down to 0 when idle, giving a 0 capacity which is not what we'd want.
Signed-off-by: Peter Zijlstra a.p.zijlstra@chello.nl Link: http://lkml.kernel.org/n/tip-wjjwelpti8f8k7i1pdnzmdr8@git.kernel.org --- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/sched.c | 55 ------------------------------------------ 2 files changed, 1 insertion(+), 56 deletions(-) delete mode 100644 arch/x86/kernel/cpu/sched.c
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 6ab6aa2..c598126 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -14,7 +14,7 @@ CFLAGS_common.o := $(nostackp)
obj-y := intel_cacheinfo.o scattered.o topology.o obj-y += proc.o capflags.o powerflags.o common.o -obj-y += vmware.o hypervisor.o sched.o mshyperv.o +obj-y += vmware.o hypervisor.o mshyperv.o obj-y += rdrand.o obj-y += match.o
diff --git a/arch/x86/kernel/cpu/sched.c b/arch/x86/kernel/cpu/sched.c deleted file mode 100644 index a640ae5..0000000 --- a/arch/x86/kernel/cpu/sched.c +++ /dev/null @@ -1,55 +0,0 @@ -#include <linux/sched.h> -#include <linux/math64.h> -#include <linux/percpu.h> -#include <linux/irqflags.h> - -#include <asm/cpufeature.h> -#include <asm/processor.h> - -#ifdef CONFIG_SMP - -static DEFINE_PER_CPU(struct aperfmperf, old_perf_sched); - -static unsigned long scale_aperfmperf(void) -{ - struct aperfmperf val, *old = &__get_cpu_var(old_perf_sched); - unsigned long ratio, flags; - - local_irq_save(flags); - get_aperfmperf(&val); - local_irq_restore(flags); - - ratio = calc_aperfmperf_ratio(old, &val); - *old = val; - - return ratio; -} - -unsigned long arch_scale_freq_power(struct sched_domain *sd, int cpu) -{ - /* - * do aperf/mperf on the cpu level because it includes things - * like turbo mode, which are relevant to full cores. - */ - if (boot_cpu_has(X86_FEATURE_APERFMPERF)) - return scale_aperfmperf(); - - /* - * maybe have something cpufreq here - */ - - return default_scale_freq_power(sd, cpu); -} - -unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu) -{ - /* - * aperf/mperf already includes the smt gain - */ - if (boot_cpu_has(X86_FEATURE_APERFMPERF)) - return SCHED_LOAD_SCALE; - - return default_scale_smt_power(sd, cpu); -} - -#endif
Heteregeneous ARM platform uses arch_scale_freq_power function to reflect the relative capacity of each core
Signed-off-by: Vincent Guittot vincent.guittot@linaro.org --- kernel/sched/features.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/features.h b/kernel/sched/features.h index de00a48..d98ae90 100644 --- a/kernel/sched/features.h +++ b/kernel/sched/features.h @@ -42,7 +42,7 @@ SCHED_FEAT(CACHE_HOT_BUDDY, true) /* * Use arch dependent cpu power functions */ -SCHED_FEAT(ARCH_POWER, false) +SCHED_FEAT(ARCH_POWER, true)
SCHED_FEAT(HRTICK, false) SCHED_FEAT(DOUBLE_TICK, false)
On Mon, 2012-07-09 at 11:27 +0200, Vincent Guittot wrote:
This patchset creates an arch_scale_freq_power function for ARM, which is used to set the relative capacity of each core of a big.LITTLE system. It also removes the broken power estimation of x86.
Modification since v3:
- Add comments
- Add optimization for SMP system
- Ensure that capacity of a CPU will be at most 1
Modification since v2:
- set_power_scale function becomes static
- Rework loop in update_siblings_masks
- Remove useless code in parse_dt_topology
Modification since v1:
- Add and update explanation about the use of the table and the range of the value
- Remove the use of NR_CPUS and use nr_cpu_ids instead
- Remove broken power estimation of x86
Peter Zijlstra (1): sched, x86: Remove broken power estimation
Note that this patch already made its way into tip as commit bcae21d6e793a7047d38abc9ac0946c53733c1dd so it might be best to base whatever tree this is supposed to fo into on something that includes that.
Vincent Guittot (4): ARM: topology: Add arch_scale_freq_power function ARM: topology: factorize the update of sibling masks ARM: topology: Update cpu_power according to DT information sched: cpu_power: enable ARCH_POWER
How would you like to proceed with these patches, I'm fine with them going through the ARM tree..
In which case:
Acked-by: Peter Zijlstra a.p.zijlstra@chello.nl
Ingo, Russell, any other preferences?
On 10 July 2012 13:27, Peter Zijlstra a.p.zijlstra@chello.nl wrote:
On Mon, 2012-07-09 at 11:27 +0200, Vincent Guittot wrote:
This patchset creates an arch_scale_freq_power function for ARM, which is used to set the relative capacity of each core of a big.LITTLE system. It also removes the broken power estimation of x86.
Modification since v3:
- Add comments
- Add optimization for SMP system
- Ensure that capacity of a CPU will be at most 1
Modification since v2:
- set_power_scale function becomes static
- Rework loop in update_siblings_masks
- Remove useless code in parse_dt_topology
Modification since v1:
- Add and update explanation about the use of the table and the range of the value
- Remove the use of NR_CPUS and use nr_cpu_ids instead
- Remove broken power estimation of x86
Peter Zijlstra (1): sched, x86: Remove broken power estimation
Note that this patch already made its way into tip as commit bcae21d6e793a7047d38abc9ac0946c53733c1dd so it might be best to base whatever tree this is supposed to fo into on something that includes that.
yes
Vincent Guittot (4): ARM: topology: Add arch_scale_freq_power function ARM: topology: factorize the update of sibling masks ARM: topology: Update cpu_power according to DT information sched: cpu_power: enable ARCH_POWER
How would you like to proceed with these patches, I'm fine with them going through the ARM tree..
May be the last one which enable ARCH_POWER should also go into tip ?
In which case:
Acked-by: Peter Zijlstra a.p.zijlstra@chello.nl
Ingo, Russell, any other preferences?
I'm going to push the patches related to ARM into Russell's patch system
Vincent
On 10 July 2012 15:42, Peter Zijlstra a.p.zijlstra@chello.nl wrote:
On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
May be the last one which enable ARCH_POWER should also go into tip ?
OK, I can take it.
Hi Peter,
I can't find the patch that enable ARCH_POWER in the tip tree. Have you take it in your tree ?
Regards, Vincent
On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote:
On 10 July 2012 15:42, Peter Zijlstra a.p.zijlstra@chello.nl wrote:
On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
May be the last one which enable ARCH_POWER should also go into tip ?
OK, I can take it.
Hi Peter,
I can't find the patch that enable ARCH_POWER in the tip tree. Have you take it in your tree ?
Uhmmm.... how about I say I have now? Sorry about that.
On 13 September 2012 14:07, Peter Zijlstra a.p.zijlstra@chello.nl wrote:
On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote:
On 10 July 2012 15:42, Peter Zijlstra a.p.zijlstra@chello.nl wrote:
On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote:
May be the last one which enable ARCH_POWER should also go into tip ?
OK, I can take it.
Hi Peter,
I can't find the patch that enable ARCH_POWER in the tip tree. Have you take it in your tree ?
Uhmmm.... how about I say I have now? Sorry about that.
ok, thanks
-
Dave Martin -
Peter Zijlstra -
Shilimkar, Santosh -
Vincent Guittot