From: Yicong Yang <yangyicong@huawei.com>
To: Valentin Schneider <vschneid@redhat.com>, <alexs@kernel.org>,
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>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
<linux-kernel@vger.kernel.org>,
<ricardo.neri-calderon@linux.intel.com>, <sshegde@linux.ibm.com>
Cc: <yangyicong@hisilicon.com>
Subject: Re: [PATCH v3 1/4] sched/fair: add SD_CLUSTER in comments
Date: Tue, 6 Feb 2024 16:21:17 +0800 [thread overview]
Message-ID: <36ca372f-5f08-5c1a-e468-4db026051e17@huawei.com> (raw)
In-Reply-To: <xhsmhzfwjgcvf.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
On 2024/2/2 22:27, Valentin Schneider wrote:
>
> Subject nit: the prefix should be sched/topology
>
> On 01/02/24 19:54, alexs@kernel.org wrote:
>> From: Alex Shi <alexs@kernel.org>
>>
>> The description of SD_CLUSTER is missing. Add it.
>>
>> Signed-off-by: Alex Shi <alexs@kernel.org>
>> To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
>> To: Valentin Schneider <vschneid@redhat.com>
>> To: Vincent Guittot <vincent.guittot@linaro.org>
>> To: Juri Lelli <juri.lelli@redhat.com>
>> To: Peter Zijlstra <peterz@infradead.org>
>> To: Ingo Molnar <mingo@redhat.com>
>> ---
>> kernel/sched/topology.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
>> index 10d1391e7416..8b45f16a1890 100644
>> --- a/kernel/sched/topology.c
>> +++ b/kernel/sched/topology.c
>> @@ -1554,6 +1554,7 @@ static struct cpumask ***sched_domains_numa_masks;
>> * function:
>> *
>> * SD_SHARE_CPUCAPACITY - describes SMT topologies
>> + * SD_CLUSTER - describes CPU Cluster topologies
>
> So I know this is the naming we've gone for the "Cluster" naming, but this
> comment isn't really explaining anything.
>
> include/linux/sched/sd_flags.h has a bit more info already:
> * Domain members share CPU cluster (LLC tags or L2 cache)
>
Cluster topology in scheduler should mean CPUs beyond the SMT which are sharing
some cache resources (currently L2 on some Intel platforms or L3 Tag on our platforms)
but not the LLC.
A drawing in c5e22feffdd7 ("topology: Represent clusters of CPUs within a die") has
a good illustration and comment of cpus_share_resources() also illustrate this a bit:
/*
* Whether CPUs are share cache resources, which means LLC on non-cluster
* machines and LLC tag or L2 on machines with clusters.
*/
bool cpus_share_resources(int this_cpu, int that_cpu)
> I had to go through a bit of git history to remember what the CLUSTER thing
> was about, how about this:
>
> * SD_CLUSTER - describes shared shared caches, cache tags or busses
> * SD_SHARE_PKG_RESOURCES - describes shared LLC cache
>
> And looking at this it would make sense to:
> rename SD_CLUSTER into SD_SHARE_PKG_RESOURCES
> rename SD_SHARE_PKG_RESOURCES into SD_SHARE_LLC
> but that's another topic...
>
>> * SD_SHARE_PKG_RESOURCES - describes shared caches
>> * SD_NUMA - describes NUMA topologies
>> *
>> --
>> 2.43.0
>
>
> .
>
prev parent reply other threads:[~2024-02-06 8:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 11:54 alexs
2024-02-01 11:54 ` [PATCH v3 2/4] sched/fair: remove unused parameters alexs
2024-02-02 14:27 ` Valentin Schneider
2024-02-05 21:26 ` Ricardo Neri
2024-02-01 11:54 ` [PATCH v3 3/4] sched/fair: packing func sched_use_asym_prio()/sched_asym_prefer() alexs
2024-02-04 11:52 ` kuiliang Shi
2024-02-05 22:09 ` Ricardo Neri
2024-02-01 11:54 ` [PATCH v3 4/4] sched/fair: Check the SD_ASYM_PACKING flag in sched_use_asym_prio() alexs
2024-02-05 22:38 ` Ricardo Neri
2024-02-06 7:57 ` kuiliang Shi
2024-02-02 14:27 ` [PATCH v3 1/4] sched/fair: add SD_CLUSTER in comments Valentin Schneider
2024-02-04 11:57 ` kuiliang Shi
2024-02-06 2:46 ` Ricardo Neri
2024-02-06 8:56 ` kuiliang Shi
2024-02-06 21:24 ` Ricardo Neri
2024-02-07 2:36 ` kuiliang Shi
2024-02-06 13:16 ` Valentin Schneider
2024-02-06 21:57 ` Ricardo Neri
2024-02-07 2:36 ` kuiliang Shi
2024-02-06 8:21 ` Yicong Yang [this message]
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=36ca372f-5f08-5c1a-e468-4db026051e17@huawei.com \
--to=yangyicong@huawei.com \
--cc=alexs@kernel.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yangyicong@hisilicon.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
Powered by JetHome