All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: "Zengtao (B)" <prime.zeng@hisilicon.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Linuxarm <linuxarm@huawei.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cpu-topology: warn if NUMA configurations conflicts with lower layer
Date: Sat, 11 Jan 2020 20:56:28 +0000	[thread overview]
Message-ID: <1a8f7963-97e9-62cc-12d2-39f816dfaf67@arm.com> (raw)
In-Reply-To: <678F3D1BB717D949B966B68EAEB446ED340BEDD6@dggemm526-mbx.china.huawei.com>

On 09/01/2020 12:58, Zengtao (B) wrote:
>> IIUC, the problem is that virt can set up a broken topology in some
>> cases where MPIDR doesn't line up correctly with the defined NUMA
>> nodes.
>>
>> We could argue that it is a qemu/virt problem, but it would be nice if
>> we could at least detect it. The proposed patch isn't really the right
>> solution as it warns on some valid topologies as Sudeep already pointed
>> out.
>>
>> It sounds more like we need a mask subset check in the sched_domain
>> building code, if there isn't already one?
> 
> Currently no, it's a bit complex to do the check in the sched_domain building code,
> I need to take a think of that.
> Suggestion welcomed.
> 

Doing a search on the sched_domain spans themselves should look something like
the completely untested:

---8<---
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 6ec1e595b1d4..96128d12ec23 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1879,6 +1879,43 @@ static struct sched_domain *build_sched_domain(struct sched_domain_topology_leve
 	return sd;
 }
 
+/* Ensure topology masks are sane; non-NUMA spans shouldn't overlap */
+static int validate_topology_spans(const struct cpumask *cpu_map)
+{
+	struct sched_domain_topology_level *tl;
+	int i, j;
+
+	for_each_sd_topology(tl) {
+		/* NUMA levels are allowed to overlap */
+		if (tl->flags & SDTL_OVERLAP)
+			break;
+
+		/*
+		 * Non-NUMA levels cannot partially overlap - they must be
+		 * either equal or wholly disjoint. Otherwise we can end up
+		 * breaking the sched_group lists - i.e. a later get_group()
+		 * pass breaks the linking done for an earlier span.
+		 */
+		for_each_cpu(i, cpu_map) {
+			for_each_cpu(j, cpu_map) {
+				if (i == j)
+					continue;
+				/*
+				 * We should 'and' all those masks with 'cpu_map'
+				 * to exactly match the topology we're about to
+				 * build, but that can only remove CPUs, which
+				 * only lessens our ability to detect overlaps
+				 */
+				if (!cpumask_equal(tl->mask(i), tl->mask(j)) &&
+				    cpumask_intersects(tl->mask(i), tl->mask(j)))
+					return -1;
+			}
+		}
+	}
+
+	return 0;
+}
+
 /*
  * Find the sched_domain_topology_level where all CPU capacities are visible
  * for all CPUs.
@@ -1953,7 +1990,8 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
 	struct sched_domain_topology_level *tl_asym;
 	bool has_asym = false;
 
-	if (WARN_ON(cpumask_empty(cpu_map)))
+	if (WARN_ON(cpumask_empty(cpu_map)) ||
+	    WARN_ON(validate_topology_spans(cpu_map)))
 		goto error;
 
 	alloc_state = __visit_domain_allocation_hell(&d, cpu_map);
--->8---

Alternatively the assertion on the sched_group linking I suggested earlier
in the thread should suffice, since this should trigger whenever we have
overlapping non-NUMA sched domains.

Since you have a setup where you can reproduce the issue, could please give
either (ideally both!) a try? Thanks.

> Thanks 
> Zengtao 
> 
>>
>> Morten

  reply	other threads:[~2020-01-11 20:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-23  8:16 [PATCH] cpu-topology: warn if NUMA configurations conflicts with lower layer z00214469
2019-12-31 16:40 ` Sudeep Holla
2020-01-02  3:05   ` Zengtao (B)
2020-01-02 11:29     ` Sudeep Holla
2020-01-02 12:47       ` Zengtao (B)
2020-01-02 13:22         ` Valentin Schneider
2020-01-02 19:30           ` Dietmar Eggemann
2020-01-03  4:24           ` Zengtao (B)
2020-01-03 10:57             ` Valentin Schneider
2020-01-03 12:14               ` Valentin Schneider
2020-01-03 17:20                 ` Dietmar Eggemann
2020-01-06  1:48                   ` Zengtao (B)
2020-01-06 14:31                     ` Dietmar Eggemann
2020-01-08  2:19                       ` Zengtao (B)
2020-01-09 11:05                       ` Morten Rasmussen
2020-01-09 12:07                         ` Dietmar Eggemann
2020-01-06  1:52                 ` Zengtao (B)
2020-01-03 11:40             ` Sudeep Holla
2020-01-06  1:37               ` Zengtao (B)
2020-01-09 10:43                 ` Morten Rasmussen
2020-01-09 12:58                   ` Zengtao (B)
2020-01-11 20:56                     ` Valentin Schneider [this message]
2020-01-13  6:51                       ` Zengtao (B)
2020-01-13 11:16                         ` Valentin Schneider
2020-01-13 12:08                           ` Zengtao (B)
2020-01-13 12:22                             ` Dietmar Eggemann
2020-01-13 14:49                       ` Dietmar Eggemann
2020-01-13 15:15                         ` Valentin Schneider
2020-01-09 10:52           ` Morten Rasmussen
2020-01-12 13:22             ` Valentin Schneider
2020-01-13 13:22               ` Morten Rasmussen
2020-01-02 13:59         ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a8f7963-97e9-62cc-12d2-39f816dfaf67@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=morten.rasmussen@arm.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.