Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp632196imm; Wed, 4 Jul 2018 03:19:59 -0700 (PDT) X-Google-Smtp-Source: AAOMgpchcNRBK0TwCa/9Amjqdk7YZoxekT/RgpL1uVHRUgYchStWFrlCbfY25fsFjjStcJn8Zs9Y X-Received: by 2002:a63:6345:: with SMTP id x66-v6mr1381629pgb.43.1530699599336; Wed, 04 Jul 2018 03:19:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530699599; cv=none; d=google.com; s=arc-20160816; b=k12hzJqO6HbwYe01fqUph6EAQmCNnUxp6wz5UUsMCxx3e3vuvjB2NA3gCR/snweDzy NDg8sFiJfET9GNiiVa/kMrxENuL4atosIN5EOuugYWMUQlFeOF+vl3GP8lPydtNjsQ12 rA5NaE95fZ7uDjojs2eubMbYb+vJxaXgtTjbcWRpZliWiwQSQFFtskzNJ/9rHhy1gtt7 kE9eFxNfsAxvH9Ga8WA7CVAvlcRrSFfF2vlYNhTTFGpXOkAUVvBca7pbF8np2gWiGOLG l03i8a5q5JNhnBpSgYz1zHrKY1q0rLozepbtgtrD38MEeE4k9aT31saQIrVtSE3iFoQY AAHw== 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=QW4qOqd2xD4LTka6Po84o79Ec5+u6SocTCA8Puy7mNM=; b=Tj+sKnUXPb6J8EOaUcKcedS9+MkyoArrPi1vWg+dGIj9w8EyGy8uQrf5ryL4Y1N7/B yqlWdHhKQaLnRQJQkJ/Va4DyzmRBwMykR8TYHcINWKcbJVSvBTqFfzfMgalJtW6UTSXx w7xtIN6/oWZ6/vHukKQ2keIXVhKYVb3GgIzfUZZNP/8pqkOyYFkzMs42yI56j/CfJ3GQ Xi/J9FiWs2W2QFpMJwj90l07Xhj/XZYF5yCC9d+Cumfa9XvtvtGEZsrP6WoNBOv+LXu0 9OVYsEXHAothpeUytb2MI7CuKwSZpuAEBBVH6Dh351HvDbjDXaVpXXGOjOdR9jC5RKev pdZA== 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 l8-v6si2860897pgq.432.2018.07.04.03.19.44; Wed, 04 Jul 2018 03:19:59 -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 S934681AbeGDKSx (ORCPT + 99 others); Wed, 4 Jul 2018 06:18:53 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35122 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934620AbeGDKSc (ORCPT ); Wed, 4 Jul 2018 06:18:32 -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 19D7D1684; Wed, 4 Jul 2018 03:18:32 -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 9739D3F5AD; Wed, 4 Jul 2018 03:18:30 -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, Morten Rasmussen Subject: [PATCHv4 12/12] sched/core: Disable SD_PREFER_SIBLING on asymmetric cpu capacity domains Date: Wed, 4 Jul 2018 11:17:50 +0100 Message-Id: <1530699470-29808-13-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 The 'prefer sibling' sched_domain flag is intended to encourage spreading tasks to sibling sched_domain to take advantage of more caches and core for SMT systems. It has recently been changed to be on all non-NUMA topology level. However, spreading across domains with cpu capacity asymmetry isn't desirable, e.g. spreading from high capacity to low capacity cpus even if high capacity cpus aren't overutilized might give access to more cache but the cpu will be slower and possibly lead to worse overall throughput. To prevent this, we need to remove SD_PREFER_SIBLING on the sched_domain level immediately below SD_ASYM_CPUCAPACITY. cc: Ingo Molnar cc: Peter Zijlstra Signed-off-by: Morten Rasmussen --- kernel/sched/topology.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 29c186961345..00c7a08c7f77 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1140,7 +1140,7 @@ sd_init(struct sched_domain_topology_level *tl, | 0*SD_SHARE_CPUCAPACITY | 0*SD_SHARE_PKG_RESOURCES | 0*SD_SERIALIZE - | 0*SD_PREFER_SIBLING + | 1*SD_PREFER_SIBLING | 0*SD_NUMA | sd_flags , @@ -1186,17 +1186,21 @@ sd_init(struct sched_domain_topology_level *tl, if (sd->flags & SD_ASYM_CPUCAPACITY) { struct sched_domain *t = sd; + /* + * Don't attempt to spread across cpus of different capacities. + */ + if (sd->child) + sd->child->flags &= ~SD_PREFER_SIBLING; + for_each_lower_domain(t) t->flags |= SD_BALANCE_WAKE; } if (sd->flags & SD_SHARE_CPUCAPACITY) { - sd->flags |= SD_PREFER_SIBLING; sd->imbalance_pct = 110; sd->smt_gain = 1178; /* ~15% */ } else if (sd->flags & SD_SHARE_PKG_RESOURCES) { - sd->flags |= SD_PREFER_SIBLING; sd->imbalance_pct = 117; sd->cache_nice_tries = 1; sd->busy_idx = 2; @@ -1207,6 +1211,7 @@ sd_init(struct sched_domain_topology_level *tl, sd->busy_idx = 3; sd->idle_idx = 2; + sd->flags &= ~SD_PREFER_SIBLING; sd->flags |= SD_SERIALIZE; if (sched_domains_numa_distance[tl->numa_level] > RECLAIM_DISTANCE) { sd->flags &= ~(SD_BALANCE_EXEC | @@ -1216,7 +1221,6 @@ sd_init(struct sched_domain_topology_level *tl, #endif } else { - sd->flags |= SD_PREFER_SIBLING; sd->cache_nice_tries = 1; sd->busy_idx = 2; sd->idle_idx = 1; -- 2.7.4