From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S947295AbdDTTxJ (ORCPT ); Thu, 20 Apr 2017 15:53:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S945001AbdDTTwa (ORCPT ); Thu, 20 Apr 2017 15:52:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E639F42BC9 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lvenanci@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E639F42BC9 From: Lauro Ramos Venancio To: Peter Zijlstra Cc: lwang@redhat.com, riel@redhat.com, Mike Galbraith , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, Lauro Ramos Venancio Subject: [PATCH 3/4] sched/topology: move comment about asymmetric node setups Date: Thu, 20 Apr 2017 16:51:42 -0300 Message-Id: <1492717903-5195-4-git-send-email-lvenanci@redhat.com> In-Reply-To: <1492717903-5195-1-git-send-email-lvenanci@redhat.com> References: <1492717903-5195-1-git-send-email-lvenanci@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 20 Apr 2017 19:52:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Signed-off-by: Lauro Ramos Venancio --- kernel/sched/topology.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 55bbaf7..e77c93a 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -495,14 +495,6 @@ enum s_alloc { /* * Build an iteration mask that can exclude certain CPUs from the upwards * domain traversal. - * - * Asymmetric node setups can result in situations where the domain tree is of - * unequal depth, make sure to skip domains that already cover the entire - * range. - * - * In that case build_sched_domains() will have terminated the iteration early - * and our sibling sd spans will be empty. Domains should always include the - * CPU they're built on, so check that. */ static void build_group_mask(struct sched_domain *sd, struct sched_group *sg) { @@ -612,7 +604,16 @@ static void init_overlap_sched_group(struct sched_domain *sd, sibling = *per_cpu_ptr(sdd->sd, i); - /* See the comment near build_group_mask(). */ + /* + * Asymmetric node setups can result in situations where the + * domain tree is of unequal depth, make sure to skip domains + * that already cover the entire range. + * + * In that case build_sched_domains() will have terminated the + * iteration early and our sibling sd spans will be empty. + * Domains should always include the CPU they're built on, so + * check that. + */ if (!cpumask_test_cpu(i, sched_domain_span(sibling))) continue; -- 1.8.3.1