Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp430286pxa; Wed, 12 Aug 2020 05:54:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtilaKrS5SoQV1c9KIfB3ceGXG6KU72TvCqhPdOLCZ9nXAHg0sDSXdZPbjIVpTMjmldkCC X-Received: by 2002:a17:906:7d90:: with SMTP id v16mr30576322ejo.27.1597236879338; Wed, 12 Aug 2020 05:54:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597236879; cv=none; d=google.com; s=arc-20160816; b=cCNdhQrYH87Ba9G0eYI5QLLT/uos7eHCS2aEAfcBwSlmszTBJH87w+qEhuoIOs7yif MJXO2WE/yjbWOTyEuu0aWxUUSvRpudfUfZ6wg/2vFfGVmfVuS5c8cgNBCwAI3y+X334y ig+tFFTdIk85b8wsGQcAMlnkmWMiHLjL9GB9W8Q2HX0fy5x9wvYNWRBPUMniyjUOL3yp UfLoS4yh0hK/9H8JDz5Wp6J8NKJR6TkobSzQIs6bnDmWHFxn7cUZ57oUKj6rI9OjVfFM IHXUYYCjYUG9q0TH3gRlCF3HmzbYXu9fDVfd046t9Jm9NwAraeWo+nVS5ifxy52HqcXW AJUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=XFkyaxunoj8jI2s80fHfT4B4DiwmcuM2aV9GZYHdoVE=; b=DSBC6Kl4NAAbRtpab6kTOqKG1QQvuyLPMPrbsqs1OoWvySzaBOM2vmf7hCxbu8p1p4 bm7F/wNjlK2RkyQSUH4wZn+iH7Lki5oS8GVerbs+sVrudA46Wj/JsH8ANXaQJazjMQj1 pCGIGe29sZofp/KmZRA5ixvoJLTigE80p8wibz7TzfCjmu+qIKWNjITLanb/HyFGF/Km 6whyq2mz1C+nLkRLHJyI78v4TlK7VcHW+2JhkwqUcS2e+5UK9uvrOdeIspLzD7WrzLPB Eq1KWA41nl6rKUbD/804kEhM38/xWxHbydOQ1LxRl4Xa79XWeOasikdtxKA9eUnp2ODS XZzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x19si983973ejb.709.2020.08.12.05.54.16; Wed, 12 Aug 2020 05:54:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727976AbgHLMxb (ORCPT + 99 others); Wed, 12 Aug 2020 08:53:31 -0400 Received: from foss.arm.com ([217.140.110.172]:44646 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728052AbgHLMx2 (ORCPT ); Wed, 12 Aug 2020 08:53:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5DB5531B; Wed, 12 Aug 2020 05:53:27 -0700 (PDT) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 269833F70D; Wed, 12 Aug 2020 05:53:26 -0700 (PDT) From: Valentin Schneider To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Quentin Perret , Dietmar Eggemann , mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, morten.rasmussen@arm.com Subject: [PATCH v5 10/17] sched/topology: Propagate SD_ASYM_CPUCAPACITY upwards Date: Wed, 12 Aug 2020 13:52:53 +0100 Message-Id: <20200812125300.11889-11-valentin.schneider@arm.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200812125300.11889-1-valentin.schneider@arm.com> References: <20200812125300.11889-1-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We currently set this flag *only* on domains whose topology level exactly match the level where we detect asymmetry (as returned by asym_cpu_capacity_level()). This is rather problematic. Say there are two clusters in the system, one with a lone big CPU and the other with a mix of big and LITTLE CPUs (as is allowed by DynamIQ): DIE [ ] MC [ ][ ] 0 1 2 3 4 L L B B B asym_cpu_capacity_level() will figure out that the MC level is the one where all CPUs can see a CPU of max capacity, and we will thus set SD_ASYM_CPUCAPACITY at MC level for all CPUs. That lone big CPU will degenerate its MC domain, since it would be alone in there, and will end up with just a DIE domain. Since the flag was only set at MC, this CPU ends up not seeing any SD with the flag set, which is broken. Rather than clearing dflags at every topology level, clear it before entering the topology level loop. This will properly propagate upwards flags that are set starting from a certain level. Reviewed-by: Quentin Perret Reviewed-by: Dietmar Eggemann Signed-off-by: Valentin Schneider --- include/linux/sched/sd_flags.h | 4 +++- kernel/sched/topology.c | 3 +-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h index 21a43ad6f26a..4f07b405564e 100644 --- a/include/linux/sched/sd_flags.h +++ b/include/linux/sched/sd_flags.h @@ -83,9 +83,11 @@ SD_FLAG(SD_WAKE_AFFINE, SDF_SHARED_CHILD) /* * Domain members have different CPU capacities * + * SHARED_PARENT: Set from the topmost domain down to the first domain where + * asymmetry is detected. * NEEDS_GROUPS: Per-CPU capacity is asymmetric between groups. */ -SD_FLAG(SD_ASYM_CPUCAPACITY, SDF_NEEDS_GROUPS) +SD_FLAG(SD_ASYM_CPUCAPACITY, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) /* * Domain members share CPU capacity (i.e. SMT) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 00ad7cef2ec1..02fd8db747b2 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1988,11 +1988,10 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att /* Set up domains for CPUs specified by the cpu_map: */ for_each_cpu(i, cpu_map) { struct sched_domain_topology_level *tl; + int dflags = 0; sd = NULL; for_each_sd_topology(tl) { - int dflags = 0; - if (tl == tl_asym) { dflags |= SD_ASYM_CPUCAPACITY; has_asym = true; -- 2.27.0