From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Steve Wahl <steve.wahl@hpe.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
linux-kernel@vger.kernel.org,
Vishal Chourasia <vishalc@linux.ibm.com>,
samir <samir@linux.ibm.com>,
Naman Jain <namjain@linux.microsoft.com>,
Saurabh Singh Sengar <ssengar@linux.microsoft.com>,
srivatsa@csail.mit.edu, Michael Kelley <mhklinux@outlook.com>,
Russ Anderson <rja@hpe.com>, Dimitri Sivanich <sivanich@hpe.com>
Subject: Re: [PATCH v4 1/2] sched/topology: improve topology_span_sane speed
Date: Thu, 12 Jun 2025 16:11:52 +0530 [thread overview]
Message-ID: <223b16a5-8532-4f5b-b34a-c7a0448f2454@amd.com> (raw)
In-Reply-To: <5a673979-e96c-4dc2-b84b-849c6c8084ae@amd.com>
On 6/12/2025 3:00 PM, K Prateek Nayak wrote:
> Ah! Since this happens so early topology isn't created yet for
> the debug prints to hit! Is it possible to get a dmesg with
> "ignore_loglevel" and "sched_verbose" on an older kernel that
> did not throw this error on the same host?
One better would be running with the following diff on top of v6.16-rc1
is possible:
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 9026d325d0fd..811c8d0f5b9a 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -2398,7 +2398,7 @@ static bool topology_span_sane(const struct cpumask *cpu_map)
{
struct sched_domain_topology_level *tl;
struct cpumask *covered, *id_seen;
- int cpu;
+ int cpu, id;
lockdep_assert_held(&sched_domains_mutex);
covered = sched_domains_tmpmask;
@@ -2421,19 +2421,21 @@ static bool topology_span_sane(const struct cpumask *cpu_map)
*/
for_each_cpu(cpu, cpu_map) {
const struct cpumask *tl_cpu_mask = tl->mask(cpu);
- int id;
/* lowest bit set in this mask is used as a unique id */
id = cpumask_first(tl_cpu_mask);
+ pr_warn("tl(%s) CPU(%d) ID(%d) CPU_TL_SPAN(%*pbl) ID_TL_SPAN(%*pbl)\n",
+ tl->name, cpu, id, cpumask_pr_args(tl->mask(cpu)), cpumask_pr_args(tl->mask(id)));
+
if (cpumask_test_cpu(id, id_seen)) {
/* First CPU has already been seen, ensure identical spans */
if (!cpumask_equal(tl->mask(id), tl_cpu_mask))
- return false;
+ goto fail;
} else {
/* First CPU hasn't been seen before, ensure it's a completely new span */
if (cpumask_intersects(tl_cpu_mask, covered))
- return false;
+ goto fail;
cpumask_or(covered, covered, tl_cpu_mask);
cpumask_set_cpu(id, id_seen);
@@ -2441,6 +2443,16 @@ static bool topology_span_sane(const struct cpumask *cpu_map)
}
}
return true;
+
+fail:
+ pr_warn("Failed tl: %s\n", tl->name);
+ pr_warn("Failed for CPU: %d\n", cpu);
+ pr_warn("ID CPU at tl: %d\n", id);
+ pr_warn("Failed CPU span at tl: %*pbl\n", cpumask_pr_args(tl->mask(cpu)));
+ pr_warn("ID CPU span: %*pbl\n", cpumask_pr_args(tl->mask(id)));
+ pr_warn("ID CPUs seen: %*pbl\n", cpumask_pr_args(id_seen));
+ pr_warn("CPUs covered: %*pbl\n", cpumask_pr_args(covered));
+ return false;
}
/*
--
In my case, it logs the following (no failures seen yet):
tl(SMT) CPU(0) ID(0) CPU_TL_SPAN(0) ID_TL_SPAN(0)
tl(SMT) CPU(1) ID(1) CPU_TL_SPAN(1) ID_TL_SPAN(1)
tl(SMT) CPU(2) ID(2) CPU_TL_SPAN(2) ID_TL_SPAN(2)
tl(SMT) CPU(3) ID(3) CPU_TL_SPAN(3) ID_TL_SPAN(3)
tl(SMT) CPU(4) ID(4) CPU_TL_SPAN(4) ID_TL_SPAN(4)
tl(SMT) CPU(5) ID(5) CPU_TL_SPAN(5) ID_TL_SPAN(5)
tl(SMT) CPU(6) ID(6) CPU_TL_SPAN(6) ID_TL_SPAN(6)
tl(SMT) CPU(7) ID(7) CPU_TL_SPAN(7) ID_TL_SPAN(7)
tl(SMT) CPU(8) ID(8) CPU_TL_SPAN(8) ID_TL_SPAN(8)
tl(SMT) CPU(9) ID(9) CPU_TL_SPAN(9) ID_TL_SPAN(9)
tl(CLS) CPU(0) ID(0) CPU_TL_SPAN(0) ID_TL_SPAN(0)
tl(CLS) CPU(1) ID(1) CPU_TL_SPAN(1) ID_TL_SPAN(1)
tl(CLS) CPU(2) ID(2) CPU_TL_SPAN(2) ID_TL_SPAN(2)
tl(CLS) CPU(3) ID(3) CPU_TL_SPAN(3) ID_TL_SPAN(3)
tl(CLS) CPU(4) ID(4) CPU_TL_SPAN(4) ID_TL_SPAN(4)
tl(CLS) CPU(5) ID(5) CPU_TL_SPAN(5) ID_TL_SPAN(5)
tl(CLS) CPU(6) ID(6) CPU_TL_SPAN(6) ID_TL_SPAN(6)
tl(CLS) CPU(7) ID(7) CPU_TL_SPAN(7) ID_TL_SPAN(7)
tl(CLS) CPU(8) ID(8) CPU_TL_SPAN(8) ID_TL_SPAN(8)
tl(CLS) CPU(9) ID(9) CPU_TL_SPAN(9) ID_TL_SPAN(9)
tl(MC) CPU(0) ID(0) CPU_TL_SPAN(0) ID_TL_SPAN(0)
tl(MC) CPU(1) ID(1) CPU_TL_SPAN(1) ID_TL_SPAN(1)
tl(MC) CPU(2) ID(2) CPU_TL_SPAN(2) ID_TL_SPAN(2)
tl(MC) CPU(3) ID(3) CPU_TL_SPAN(3) ID_TL_SPAN(3)
tl(MC) CPU(4) ID(4) CPU_TL_SPAN(4) ID_TL_SPAN(4)
tl(MC) CPU(5) ID(5) CPU_TL_SPAN(5) ID_TL_SPAN(5)
tl(MC) CPU(6) ID(6) CPU_TL_SPAN(6) ID_TL_SPAN(6)
tl(MC) CPU(7) ID(7) CPU_TL_SPAN(7) ID_TL_SPAN(7)
tl(MC) CPU(8) ID(8) CPU_TL_SPAN(8) ID_TL_SPAN(8)
tl(MC) CPU(9) ID(9) CPU_TL_SPAN(9) ID_TL_SPAN(9)
tl(PKG) CPU(0) ID(0) CPU_TL_SPAN(0-1) ID_TL_SPAN(0-1)
tl(PKG) CPU(1) ID(0) CPU_TL_SPAN(0-1) ID_TL_SPAN(0-1)
tl(PKG) CPU(2) ID(2) CPU_TL_SPAN(2-3) ID_TL_SPAN(2-3)
tl(PKG) CPU(3) ID(2) CPU_TL_SPAN(2-3) ID_TL_SPAN(2-3)
tl(PKG) CPU(4) ID(4) CPU_TL_SPAN(4-5) ID_TL_SPAN(4-5)
tl(PKG) CPU(5) ID(4) CPU_TL_SPAN(4-5) ID_TL_SPAN(4-5)
tl(PKG) CPU(6) ID(6) CPU_TL_SPAN(6-7) ID_TL_SPAN(6-7)
tl(PKG) CPU(7) ID(6) CPU_TL_SPAN(6-7) ID_TL_SPAN(6-7)
tl(PKG) CPU(8) ID(8) CPU_TL_SPAN(8-9) ID_TL_SPAN(8-9)
tl(PKG) CPU(9) ID(8) CPU_TL_SPAN(8-9) ID_TL_SPAN(8-9)
tl(NODE) CPU(0) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(1) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(2) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(3) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(4) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(5) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(6) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(7) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(8) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
tl(NODE) CPU(9) ID(0) CPU_TL_SPAN(0-9) ID_TL_SPAN(0-9)
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2025-06-12 10:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 16:08 [PATCH v4 0/2] Improving topology_span_sane Steve Wahl
2025-03-04 16:08 ` [PATCH v4 1/2] sched/topology: improve topology_span_sane speed Steve Wahl
2025-04-08 19:05 ` [tip: sched/core] " tip-bot2 for Steve Wahl
2025-06-10 11:07 ` [PATCH v4 1/2] " Leon Romanovsky
2025-06-10 11:33 ` K Prateek Nayak
2025-06-10 12:36 ` Leon Romanovsky
2025-06-10 13:09 ` Leon Romanovsky
2025-06-10 19:39 ` Steve Wahl
2025-06-11 6:06 ` Leon Romanovsky
2025-06-11 6:56 ` K Prateek Nayak
2025-06-12 7:41 ` Leon Romanovsky
2025-06-12 9:30 ` K Prateek Nayak
2025-06-12 10:41 ` K Prateek Nayak [this message]
2025-06-15 6:42 ` Leon Romanovsky
2025-06-16 14:18 ` Steve Wahl
2025-06-17 3:04 ` K Prateek Nayak
2025-06-17 7:55 ` Leon Romanovsky
2025-06-17 7:34 ` Leon Romanovsky
2025-06-17 9:22 ` K Prateek Nayak
2025-06-23 6:06 ` K Prateek Nayak
2025-03-04 16:08 ` [PATCH v4 2/2] sched/topology: Refinement to topology_span_sane speedup Steve Wahl
2025-04-08 19:05 ` [tip: sched/core] " tip-bot2 for Steve Wahl
2025-03-06 6:46 ` [PATCH v4 0/2] Improving topology_span_sane K Prateek Nayak
2025-03-06 14:33 ` Valentin Schneider
2025-03-07 10:06 ` Madadi Vineeth Reddy
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=223b16a5-8532-4f5b-b34a-c7a0448f2454@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=namjain@linux.microsoft.com \
--cc=peterz@infradead.org \
--cc=rja@hpe.com \
--cc=rostedt@goodmis.org \
--cc=samir@linux.ibm.com \
--cc=sivanich@hpe.com \
--cc=srivatsa@csail.mit.edu \
--cc=ssengar@linux.microsoft.com \
--cc=steve.wahl@hpe.com \
--cc=vincent.guittot@linaro.org \
--cc=vishalc@linux.ibm.com \
--cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®