From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Gautham R Shenoy <ego@linux.vnet.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>,
Michael Neuling <mikey@neuling.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
Valentin Schneider <valentin.schneider@arm.com>,
Oliver O'Halloran <oohall@gmail.com>,
Jordan Niethe <jniethe5@gmail.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v3 09/10] powerpc/smp: Create coregroup domain
Date: Mon, 27 Jul 2020 16:48:45 +0530 [thread overview]
Message-ID: <20200727111845.GA11819@linux.vnet.ibm.com> (raw)
In-Reply-To: <20200727043941.GA18303@in.ibm.com>
* Gautham R Shenoy <ego@linux.vnet.ibm.com> [2020-07-27 10:09:41]:
> >
> > static void fixup_topology(void)
> > {
> > + if (!has_coregroup_support())
> > + powerpc_topology[mc_idx].mask = cpu_bigcore_mask;
> > +
> > if (shared_caches) {
> > pr_info("Using shared cache scheduler topology\n");
> > powerpc_topology[bigcore_idx].mask = shared_cache_mask;
>
>
> Suppose we consider a topology which does not have coregroup_support,
> but has shared_caches. In that case, we would want our coregroup
> domain to degenerate.
>
> From the above code, after the fixup, our topology will look as
> follows:
>
> static struct sched_domain_topology_level powerpc_topology[] = {
> { cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
> { shared_cache_mask, powerpc_shared_cache_flags, SD_INIT_NAME(CACHE) },
> { cpu_bigcore_mask, SD_INIT_NAME(MC) },
> { cpu_cpu_mask, SD_INIT_NAME(DIE) },
> { NULL, },
>
> So, in this case, the core-group domain (identified by MC) will
> degenerate only if cpu_bigcore_mask() and shared_cache_mask() return
> the same value. This may work for existing platforms, because either
> shared_caches don't exist, or when they do, cpu_bigcore_mask and
> shared_cache_mask return the same set of CPUs. But this may or may not
> continue to hold good in the future.
>
> Furthermore, if that is always going to be the case that in the
> presence of shared_caches the cpu_bigcore_mask() and
> shared_cache_mask() will always be the same, then why even define two
> separate masks and not just have only the cpu_bigcore_mask() ?
>
Your two statements are contradicting. In the former you are saying we
should be future proof and in the latter, you are asking for why add if they
are both going to be the same.
> The correct way would be to set the powerpc_topology[mc_idx].mask to
> powerpc_topology[bigcore_idx].mask *after* we have fixedup the
> big_core level.
The reason I modified it in v4 is not for degeneration or for future case
but for the current PowerNV/SMT 4 case. I could have as well detected the
the same and modified bigcore but thought fixup at one place would be
better.
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2020-07-27 11:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 8:51 [PATCH v3 00/10] Coregroup support on Powerpc Srikar Dronamraju
2020-07-23 8:51 ` [PATCH v3 01/10] powerpc/smp: Fix a warning under !NEED_MULTIPLE_NODES Srikar Dronamraju
2020-07-23 8:51 ` [PATCH v3 02/10] powerpc/smp: Merge Power9 topology with Power topology Srikar Dronamraju
2020-07-24 7:06 ` Gautham R Shenoy
2020-07-23 8:51 ` [PATCH v3 03/10] powerpc/smp: Move powerpc_topology above Srikar Dronamraju
2020-07-23 8:51 ` [PATCH v3 04/10] powerpc/smp: Move topology fixups into a new function Srikar Dronamraju
2020-07-24 7:08 ` Gautham R Shenoy
2020-07-23 8:51 ` [PATCH v3 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling Srikar Dronamraju
2020-07-24 7:11 ` Gautham R Shenoy
2020-07-23 8:51 ` [PATCH v3 06/10] powerpc/smp: Generalize 2nd sched domain Srikar Dronamraju
2020-07-23 8:51 ` [PATCH v3 07/10] powerpc/numa: Detect support for coregroup Srikar Dronamraju
2020-07-23 8:51 ` [PATCH v3 08/10] powerpc/smp: Allocate cpumask only after searching thread group Srikar Dronamraju
2020-07-23 8:51 ` [PATCH v3 09/10] powerpc/smp: Create coregroup domain Srikar Dronamraju
2020-07-27 4:39 ` Gautham R Shenoy
2020-07-27 11:18 ` Srikar Dronamraju [this message]
2020-07-23 8:51 ` [PATCH v3 10/10] powerpc/smp: Implement cpu_to_coregroup_id Srikar Dronamraju
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=20200727111845.GA11819@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=ego@linux.vnet.ibm.com \
--cc=jniethe5@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=mingo@kernel.org \
--cc=nathanl@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=oohall@gmail.com \
--cc=peterz@infradead.org \
--cc=valentin.schneider@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).