On Wed, 2015-05-13 at 12:15 -0400, Jorge Ramirez-Ortiz wrote:
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.
This email thread on the Linaro Kernel list is the first I've seen of any of this. And in general, the ARM LT doesn't actually do any work on this code, we just seem to be the delivery path for work done by others, and we don't usually get to hear about that work until they until they want it in LSK.