Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp633153imm; Wed, 4 Jul 2018 03:21:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdbOIetcTcTPZWlSsGZlJYqJtGnoeLl59v+Xs1YWWh9FDlK9r32KA7IpNysAvxK0TJidzmJ X-Received: by 2002:a62:6147:: with SMTP id v68-v6mr1541868pfb.115.1530699673603; Wed, 04 Jul 2018 03:21:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530699673; cv=none; d=google.com; s=arc-20160816; b=dS9nlXJOAaDn3x4dWsilLy902lkTzmrvg+45YSlSDFJE5kDVjH3WwBLjvrwZ/x/pwo C+PkxjZl+hTbYoDW6tMKVTJot42i3AryGUVVGwMoBWavvVJSBf0MhQdi/SYN8V4mkdUg CatQrkjfOBoHO504h+4YlDuJ8aO44+3/cSmwMSgsyxrmxr4Bhtzdd+n29Iml/o4X7Sxa YAJbRncpgPUqDaqOcXJHJhfeL80dWdpz1q4uVCyertIaUIia6Is2rQCGE6gPtvWi8eq8 cqZp0Lk/STCq2vT1gytLmrQNltWWqzoSrmdrUqzUfNPMOYwlV6jUz+/uSQiq3+wUUOBi NMcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=ezDkSk2bpmjcx9a+koLHGyn3wcbNtS5jyxz6EXdImjk=; b=pZ+/dfKIgj2FGdN9lsP/vMC/ppXEJ48EW8WB0429ZutTmsRlPaDkGZdR3YC14gIGNo 1UULFGmb8xXe8oY/YrkHqTkoCpnZswGYHV2oRmJZZnmIjjmBsSP/YmXSwHA1boq4RPPX z3j/PL9C95233Kvrnu+k68hawLFj6LkILjaezqZCM/8rfYGE151s5VCXS6vmNFc15E3E ICoMs2kSD/TPIyy0Zy0Bph6wQtvBNpPe89qYcR6WM+sAWonCuHYMIK8zBlg+r5S6tCaR pfCp8F97y8JqU9uBJA7KfjlC2WZ0CiP4lIjEQi4eg1Iff2NnGD1/Zo5Fb9Z0bQkgaENJ evqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x19-v6si3135360plr.15.2018.07.04.03.20.59; Wed, 04 Jul 2018 03:21:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934164AbeGDKTV (ORCPT + 99 others); Wed, 4 Jul 2018 06:19:21 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35094 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934162AbeGDKS2 (ORCPT ); Wed, 4 Jul 2018 06:18:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 980AE1529; Wed, 4 Jul 2018 03:18:28 -0700 (PDT) Received: from e105550-lin.cambridge.arm.com (e105550-lin.cambridge.arm.com [10.1.211.30]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F226A3F5AD; Wed, 4 Jul 2018 03:18:26 -0700 (PDT) From: Morten Rasmussen To: peterz@infradead.org, mingo@redhat.com Cc: valentin.schneider@arm.com, dietmar.eggemann@arm.com, vincent.guittot@linaro.org, gaku.inami.xh@renesas.com, linux-kernel@vger.kernel.org, Chris Redpath , Morten Rasmussen Subject: [PATCHv4 10/12] sched/fair: Don't move tasks to lower capacity cpus unless necessary Date: Wed, 4 Jul 2018 11:17:48 +0100 Message-Id: <1530699470-29808-11-git-send-email-morten.rasmussen@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1530699470-29808-1-git-send-email-morten.rasmussen@arm.com> References: <1530699470-29808-1-git-send-email-morten.rasmussen@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chris Redpath When lower capacity CPUs are load balancing and considering to pull something from a higher capacity group, we should not pull tasks from a cpu with only one task running as this is guaranteed to impede progress for that task. If there is more than one task running, load balance in the higher capacity group would have already made any possible moves to resolve imbalance and we should make better use of system compute capacity by moving a task if we still have more than one running. cc: Ingo Molnar cc: Peter Zijlstra Signed-off-by: Chris Redpath Signed-off-by: Morten Rasmussen --- kernel/sched/fair.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index de84f5a9a65a..06beefa02420 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8793,6 +8793,17 @@ static struct rq *find_busiest_queue(struct lb_env *env, capacity = capacity_of(i); + /* + * For ASYM_CPUCAPACITY domains, don't pick a cpu that could + * eventually lead to active_balancing high->low capacity. + * Higher per-cpu capacity is considered better than balancing + * average load. + */ + if (env->sd->flags & SD_ASYM_CPUCAPACITY && + capacity_of(env->dst_cpu) < capacity && + rq->nr_running == 1) + continue; + wl = weighted_cpuload(rq); /* -- 2.7.4