On 05/13/2015 11:53 AM, Vincent Guittot wrote:
On 13 May 2015 at 17:06, Jorge Ramirez-Ortiz jorge.ramirez-ortiz@linaro.org wrote:
From: Jorge Ramirez-Ortiz jro@xenomai.org
The current arm64 power scaling calculations deviate from the arm implementation causing scheduling problems on non bigLITTLE architectures (this could be due to baseline/merging issues).
The proposed workaround uses the middle_capacity weighting factor to guarantee that all CPUs report the same power (1024) on non bigLITTLE SoC.
Signed-off-by: Jorge Ramirez-Ortiz jro@xenomai.org
arch/arm64/kernel/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c index db8bb29..65837c2 100644 --- a/arch/arm64/kernel/topology.c +++ b/arch/arm64/kernel/topology.c @@ -325,7 +325,7 @@ static void __init parse_dt_cpu_power(void) * constraint explained near table_efficiency[]. */ if (min_capacity == max_capacity)
return;
middle_capacity = max_capacity >> SCHED_POWER_SHIFT;You should probably remove the if (min_capacity == max_capacity) condition like what is done in Arm 32bits ?
yes I did look into following the arm implementation, but since doing that is a larger change and I didnt know if someone (arm LT) was already working on a merge I opted for a simple scaling factor until the merge happens.
but of course I agree with you, we have to keep a single algorithm (I remember you mentioning).