From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932436AbdJJR7m (ORCPT ); Tue, 10 Oct 2017 13:59:42 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:46619 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755818AbdJJR7l (ORCPT ); Tue, 10 Oct 2017 13:59:41 -0400 Subject: Re: [PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling code path To: Atish Patra , linux-kernel@vger.kernel.org, eas-dev@lists.linaro.org Cc: peterz@infradead.org, mingo@redhat.com, joelaf@google.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, morten.rasmussen@arm.com References: <1507420114-12708-1-git-send-email-rohit.k.jain@oracle.com> <1507420114-12708-3-git-send-email-rohit.k.jain@oracle.com> <49cc651e-5cbc-2924-34aa-2bb271d0a0d6@oracle.com> From: Rohit Jain Message-ID: <34e1c88e-15d9-af44-2442-25ab1fcf43a1@oracle.com> Date: Tue, 10 Oct 2017 11:02:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <49cc651e-5cbc-2924-34aa-2bb271d0a0d6@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Atish, Thanks for the comments On 10/10/2017 08:54 AM, Atish Patra wrote: > >> >> Signed-off-by: Rohit Jain >> --- >>   kernel/sched/fair.c | 37 ++++++++++++++++++++++++++++--------- >>   1 file changed, 28 insertions(+), 9 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index eaede50..5b1f7b9 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -6004,7 +6004,7 @@ static int select_idle_core(struct task_struct >> *p, struct sched_domain *sd, int >>             for_each_cpu(cpu, cpu_smt_mask(core)) { >>               cpumask_clear_cpu(cpu, cpus); >> -            if (!idle_cpu(cpu)) >> +            if (!idle_cpu(cpu) || !full_capacity(cpu)) > Do we need to skip the entire core just because 1st cpu in the core > doesn't have full capacity ? > Let's say that is the only idle core available. It will go and try to > select_idle_cpu() to find the idlest cpu. > Is it worth spending extra time to search an idle cpu with full > capacity when there are idle cores available ? This has been previously discussed: https://lkml.org/lkml/2017/10/3/1001 Returning the best CPU within the idle core did not result in a statistically significant performance benefit, hence I went with Joel's suggestion to keep the code simple. Thanks, Rohit