Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161998AbbBDShv (ORCPT ); Wed, 4 Feb 2015 13:37:51 -0500 Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:41633 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161688AbbBDSb1 (ORCPT ); Wed, 4 Feb 2015 13:31:27 -0500 From: Morten Rasmussen To: peterz@infradead.org, mingo@redhat.com Cc: vincent.guittot@linaro.org, dietmar.eggemann@arm.com, yuyang.du@intel.com, preeti@linux.vnet.ibm.com, mturquette@linaro.org, nico@linaro.org, rjw@rjwysocki.net, juri.lelli@arm.com, linux-kernel@vger.kernel.org Subject: [RFCv3 PATCH 28/48] sched: Use capacity_curr to cap utilization in get_cpu_usage() Date: Wed, 4 Feb 2015 18:31:05 +0000 Message-Id: <1423074685-6336-29-git-send-email-morten.rasmussen@arm.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2542 Lines: 57 With scale-invariant usage tracking get_cpu_usage() should never return a usage above the current compute capacity of the cpu (capacity_curr). The scaling of the utilization tracking contributions should generally cause the cpu utilization to saturate at capacity_curr, but it may temporarily exceed this value in certain situations. This patch changes the cap from capacity_orig to capacity_curr. cc: Ingo Molnar cc: Peter Zijlstra Signed-off-by: Morten Rasmussen --- kernel/sched/fair.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 071310a..872ae0e 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4582,13 +4582,13 @@ static unsigned long capacity_curr_of(int cpu) * cpu_capacity). * cfs.utilization_load_avg is the sum of running time of runnable tasks on a * CPU. It represents the amount of utilization of a CPU in the range - * [0..SCHED_LOAD_SCALE]. The usage of a CPU can't be higher than the full + * [0..capacity_curr]. The usage of a CPU can't be higher than the current * capacity of the CPU because it's about the running time on this CPU. - * Nevertheless, cfs.utilization_load_avg can be higher than SCHED_LOAD_SCALE + * Nevertheless, cfs.utilization_load_avg can be higher than capacity_curr * because of unfortunate rounding in avg_period and running_load_avg or just * after migrating tasks until the average stabilizes with the new running * time. So we need to check that the usage stays into the range - * [0..cpu_capacity_orig] and cap if necessary. + * [0..cpu_capacity_curr] and cap if necessary. * Without capping the usage, a group could be seen as overloaded (CPU0 usage * at 121% + CPU1 usage at 80%) whereas CPU1 has 20% of available capacity/ */ @@ -4596,9 +4596,10 @@ static int get_cpu_usage(int cpu) { unsigned long usage = cpu_rq(cpu)->cfs.utilization_load_avg; unsigned long blocked = cpu_rq(cpu)->cfs.utilization_blocked_avg; + unsigned long capacity_curr = capacity_curr_of(cpu); - if (usage + blocked >= SCHED_LOAD_SCALE) - return capacity_orig_of(cpu); + if (usage + blocked >= capacity_curr) + return capacity_curr; return usage + blocked; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/