Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030807AbbD1Qyr (ORCPT ); Tue, 28 Apr 2015 12:54:47 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:8786 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030718AbbD1Qyo convert rfc822-to-8bit (ORCPT ); Tue, 28 Apr 2015 12:54:44 -0400 Message-ID: <553FBB4E.4050707@arm.com> Date: Tue, 28 Apr 2015 17:54:38 +0100 From: Dietmar Eggemann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "pang.xunlei@zte.com.cn" , Morten Rasmussen CC: Juri Lelli , "linux-kernel@vger.kernel.org" , "linux-kernel-owner@vger.kernel.org" , "mingo@redhat.com" , "mturquette@linaro.org" , "nico@linaro.org" , "peterz@infradead.org" , "preeti@linux.vnet.ibm.com" , "rjw@rjwysocki.net" , "vincent.guittot@linaro.org" , "yuyang.du@intel.com" Subject: Re: [RFCv3 PATCH 17/48] sched: Get rid of scaling usage by cpu_capacity_orig References: <1423074685-6336-1-git-send-email-morten.rasmussen@arm.com> <1423074685-6336-18-git-send-email-morten.rasmussen@arm.com> In-Reply-To: X-OriginalArrivalTime: 28 Apr 2015 16:54:38.0490 (UTC) FILETIME=[03769FA0:01D081D4] X-MC-Unique: l8mdQjPfSVSpQPYbi4lSKw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2407 Lines: 57 On 28/04/15 08:12, pang.xunlei@zte.com.cn wrote: > Morten Rasmussen wrote 2015-02-05 AM 02:30:54: >> From: Dietmar Eggemann >> >> Since now we have besides frequency invariant also cpu (uarch plus max >> system frequency) invariant cfs_rq::utilization_load_avg both, frequency >> and cpu scaling happens as part of the load tracking. >> So cfs_rq::utilization_load_avg does not have to be scaled by the original >> capacity of the cpu again. >> >> Cc: Ingo Molnar >> Cc: Peter Zijlstra >> Signed-off-by: Dietmar Eggemann >> --- >> kernel/sched/fair.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 5375ab1..a85c34b 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -4807,12 +4807,11 @@ static int select_idle_sibling(struct >> task_struct *p, int target) >> static int get_cpu_usage(int cpu) >> { >> unsigned long usage = cpu_rq(cpu)->cfs.utilization_load_avg; >> - unsigned long capacity = capacity_orig_of(cpu); >> >> if (usage >= SCHED_LOAD_SCALE) > > Since utilization_load_avg has been applied all the scaling, > it can't exceed its original capacity. SCHED_LOAD_SCALE is > the max original capacity of all, right? > > So, shouldn't this be "if(usage >= orig_capacity)"? Absolutely, you're right. The usage on cpus which have a smaller orig capacity (<1024) than the cpus with the highest orig capacity (1024) have to be limited to their orig capacity. There is another patch in this series '[RFCv3 PATCH 28/48] sched: Use capacity_curr to cap utilization in get_cpu_usage()' which changes the upper bound from SCHED_LOAD_SCALE to capacity_curr_of(cpu) and returns this current capacity in case the usage (running and blocked) exceeds it. Our testing in the meantime has shown that this is the wrong approach in some cases. Like adding more tasks to a cpu and deciding the new capacity state (OPP) based on get_cpu_usage(). We are likely to change this to capacity_orig_of(cpu) in the next version. [...] -- 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/