All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naman Jain <namjain@linux.microsoft.com>
To: Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	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>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	Steve Wahl <steve.wahl@hpe.com>,
	Saurabh Singh Sengar <ssengar@linux.microsoft.com>,
	srivatsa@csail.mit.edu, Michael Kelley <mhklinux@outlook.com>
Subject: Re: [PATCH v3] sched/topology: Enable topology_span_sane check only for debug builds
Date: Thu, 6 Feb 2025 22:48:10 +0530	[thread overview]
Message-ID: <464cdd27-464c-423e-b07f-cfb641a6a025@linux.microsoft.com> (raw)
In-Reply-To: <xhsmhed0bjdum.mognet@vschneid-thinkpadt14sgen2i.remote.csb>



On 2/6/2025 8:54 PM, Valentin Schneider wrote:
> On 06/02/25 14:40, K Prateek Nayak wrote:
>> What topology_span_sane() does is, it iterates over all the CPUs at a
>> given topology level and makes sure that the cpumask for a CPU at
>> that domain is same as the cpumask of every other CPU set on that mask
>> for that topology level.
>>
>> If two CPUs are set on a mask, they should have the same mask. If CPUs
>> are not set on each other's mask, the masks should be disjoint.
>>
>> On x86, the way set_cpu_sibling_map() works, CPUs are set on each other's
>> shared masks iff match_*() returns true:
>>
>> o For SMT, this means:
>>
>>     - If X86_FEATURE_TOPOEXT is set:
>>       - pkg_id must match.
>>       - die_id must match.
>>       - amd_node_id must match.
>>       - llc_id must match.
>>       - Either core_id or cu_id must match. (*)
>>       - NUMA nodes must match.
>>
>>     - If !X86_FEATURE_TOPOEXT:
>>       - pkg_id must match.
>>       - die_id must match.
>>       - core_id must match.
>>       - NUMA nodes must match.
>>
>> o For CLUSTER this means:
>>
>>     - If l2c_id is not populated (== BAD_APICID)
>>       - Same conditions as SMT.
>>
>>     - If l2c_id is populated (!= BAD_APICID)
>>       - l2c_id must match.
>>       - NUMA nodes must match.
>>
>> o For MC it means:
>>
>>     - llc_id must be populated (!= BAD_APICID) and must match.
>>     - If INTEL_SNC: pkg_id must match.
>>     - If !INTEL_SNC: NUMA nodes must match.
>>
>> o For PKG domain:
>>
>>     - Inserted only if !x86_has_numa_in_package.
>>     - CPUs should be in same NUMA node.
>>
>> All in all, other that the one (*) decision point, everything else has
>> to strictly match for CPUs to be set in each other's CPU mask. And if
>> they match with one CPU, they should match will all other CPUs in mask
>> and it they mismatch with one, they should mismatch with all leading
>> to link_mask() never being called.
>>
> 
> Nice summary, thanks for that - I'm not that familiar with the x86 topology
> faff.
> 
> 
>> This is why I think that the topology_span_sane() check is redundant
>> when the x86 bits have already ensured masks cannot overlap in all
>> cases except for potentially in the (*) case.
>>
>> So circling back to my original question around "SDTL_ARCH_VERIFIED",
>> would folks be okay to an early bailout from topology_span_sane() on:
>>
>>       if (!sched_debug() && (tl->flags & SDTL_ARCH_VERIFIED))
>>        return;
>>
>> and more importantly, do folks care enough about topology_span_sane()
>> to have it run on other architectures and not just have it guarded
>> behind just "sched_debug()" which starts off as false by default?
>>
> 
> If/when possible I prefer to have sanity checks run unconditionally, as
> long as they don't noticeably impact runtime. Unfortunately this does show
> up in the boot time, though Steve had a promising improvement for that.
> 
> Anyway, if someone gets one of those hangs on a
> 
>    do { } while (group != sd->groups)
> 
> they'll quickly turn on sched_verbose (or be told to) and the sanity check
> will holler at them, so I'm not entirely against it.


Thanks for the feedback :)

Regards,
Naman

  parent reply	other threads:[~2025-02-06 17:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03 11:47 [PATCH v3] sched/topology: Enable topology_span_sane check only for debug builds Naman Jain
2025-02-05  7:20 ` K Prateek Nayak
2025-02-05  7:23   ` Naman Jain
2025-02-10  9:53     ` Naman Jain
2025-02-05  9:48 ` K Prateek Nayak
2025-02-05  9:55   ` Peter Zijlstra
2025-02-05 10:13     ` K Prateek Nayak
2025-02-05 10:16       ` Peter Zijlstra
2025-02-06  9:10         ` K Prateek Nayak
2025-02-06  9:47           ` Naman Jain
2025-02-06 10:19             ` K Prateek Nayak
2025-02-06 10:55               ` Naman Jain
2025-02-06 15:24           ` Valentin Schneider
2025-02-06 15:30             ` Steve Wahl
2025-02-06 17:18             ` Naman Jain [this message]
2025-02-07  2:44             ` K Prateek Nayak
2025-02-11  5:52   ` Shrikanth Hegde
2025-02-11  7:06     ` Naman Jain
2025-02-11 10:56     ` K Prateek Nayak

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=464cdd27-464c-423e-b07f-cfb641a6a025@linux.microsoft.com \
    --to=namjain@linux.microsoft.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhklinux@outlook.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=srivatsa@csail.mit.edu \
    --cc=ssengar@linux.microsoft.com \
    --cc=stable@vger.kernel.org \
    --cc=steve.wahl@hpe.com \
    --cc=vincent.guittot@linaro.org \
    --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 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.