All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gautham R Shenoy <ego@linux.vnet.ibm.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>,
	Gautham R Shenoy <ego@linux.vnet.ibm.com>,
	Oliver OHalloran <oliveroh@au1.ibm.com>,
	Michael Neuling <mikey@linux.ibm.com>,
	Michael Ellerman <michaele@au1.ibm.com>,
	Anton Blanchard <anton@au1.ibm.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Nick Piggin <npiggin@au1.ibm.com>
Subject: Re: [PATCH 06/11] powerpc/smp: Generalize 2nd sched domain
Date: Mon, 20 Jul 2020 14:37:02 +0530	[thread overview]
Message-ID: <20200720090702.GB6680@in.ibm.com> (raw)
In-Reply-To: <20200720061911.GC21103@linux.vnet.ibm.com>

On Mon, Jul 20, 2020 at 11:49:11AM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy <ego@linux.vnet.ibm.com> [2020-07-17 12:07:55]:
> 
> > On Tue, Jul 14, 2020 at 10:06:19AM +0530, Srikar Dronamraju wrote:
> > > Currently "CACHE" domain happens to be the 2nd sched domain as per
> > > powerpc_topology. This domain will collapse if cpumask of l2-cache is
> > > same as SMT domain. However we could generalize this domain such that it
> > > could mean either be a "CACHE" domain or a "BIGCORE" domain.
> > > 
> > > While setting up the "CACHE" domain, check if shared_cache is already
> > > set.
> > > 
> > > Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
> > > Cc: Michael Ellerman <michaele@au1.ibm.com>
> > > Cc: Nick Piggin <npiggin@au1.ibm.com>
> > > Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
> > > Cc: Nathan Lynch <nathanl@linux.ibm.com>
> > > Cc: Michael Neuling <mikey@linux.ibm.com>
> > > Cc: Anton Blanchard <anton@au1.ibm.com>
> > > Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
> > > Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
> > > Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> > > ---
> > > @@ -867,11 +869,16 @@ static const struct cpumask *smallcore_smt_mask(int cpu)
> > >  }
> > >  #endif
> > > 
> > > +static const struct cpumask *cpu_bigcore_mask(int cpu)
> > > +{
> > > +	return cpu_core_mask(cpu);
> > 
> > It should be cpu_smt_mask() if we want the redundant big-core to be
> > degenerated in favour of the SMT level on P8, no? Because
> > cpu_core_mask refers to all the CPUs that are in the same chip.
> > 
> 
> Right, but it cant be cpu_smt_mask since cpu_smt_mask is only enabled in
> CONFIG_SCHED_SMT. I was looking at using sibling_map, but we have to careful
> for power9 / PowerNV mode. Guess that should be fine.

Ok.

> 
> > > +}
> > > +
> > >  static struct sched_domain_topology_level powerpc_topology[] = {
> > >  #ifdef CONFIG_SCHED_SMT
> > >  	{ cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
> > >  #endif
> > > -	{ shared_cache_mask, powerpc_shared_cache_flags, SD_INIT_NAME(CACHE) },
> > > +	{ cpu_bigcore_mask, SD_INIT_NAME(BIGCORE) },
> > >  	{ cpu_cpu_mask, SD_INIT_NAME(DIE) },
> > >  	{ NULL, },
> > >  };
> > > @@ -1319,7 +1326,6 @@ static void add_cpu_to_masks(int cpu)
> > >  void start_secondary(void *unused)
> > >  {
> > >  	unsigned int cpu = smp_processor_id();
> > > -	struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
> > > 
> > >  	mmgrab(&init_mm);
> > >  	current->active_mm = &init_mm;
> > > @@ -1345,14 +1351,20 @@ void start_secondary(void *unused)
> > >  	/* Update topology CPU masks */
> > >  	add_cpu_to_masks(cpu);
> > > 
> > > -	if (has_big_cores)
> > > -		sibling_mask = cpu_smallcore_mask;
> > >  	/*
> > >  	 * Check for any shared caches. Note that this must be done on a
> > >  	 * per-core basis because one core in the pair might be disabled.
> > >  	 */
> > > -	if (!cpumask_equal(cpu_l2_cache_mask(cpu), sibling_mask(cpu)))
> > > -		shared_caches = true;
> > > +	if (!shared_caches) {
> > > +		struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
> > > +		struct cpumask *mask = cpu_l2_cache_mask(cpu);
> > > +
> > > +		if (has_big_cores)
> > > +			sibling_mask = cpu_smallcore_mask;
> > > +
> > > +		if (cpumask_weight(mask) > cpumask_weight(sibling_mask(cpu)))
> > > +			shared_caches = true;
> > 
> > Shouldn't we use cpumask_subset() here ?
> 
> Wouldn't cpumask_subset should return 1 if both are same?

When are caches shared ? When the sibling_mask(cpu)  is a
strict-subset of cpu_l2_cache_mask(cpu). cpumask_weight() only
checks if the number of CPUs in cpu_l2_cache_mask(cpu) is greater than
sibling_mask(cpu) but not if constituent CPUs of the former forms
a strict superset of the latter.

We are better off using
if (!cpumask_equal(sibling_mask(cpu), mask) &&
    cpumask_subset(sibling_mask(cpu), mask))

which is accurate.



> We dont want to have shared_caches set if both the masks are equal.


> 
> >   			
> > > +	}
> > > 
> > >  	set_numa_node(numa_cpu_lookup_table[cpu]);
> > >  	set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
> > > @@ -1390,6 +1402,14 @@ void __init smp_cpus_done(unsigned int max_cpus)
> > >  		smp_ops->bringup_done();
> > > 
> > >  	dump_numa_cpu_topology();
> > > +	if (shared_caches) {
> > > +		pr_info("Using shared cache scheduler topology\n");
> > > +		powerpc_topology[bigcore_idx].mask = shared_cache_mask;
> > > +#ifdef CONFIG_SCHED_DEBUG
> > > +		powerpc_topology[bigcore_idx].name = "CACHE";
> > > +#endif
> > > +		powerpc_topology[bigcore_idx].sd_flags = powerpc_shared_cache_flags;
> > > +	}
> > 
> > 
> > I would much rather that we have all the topology-fixups done in one
> > function.
> > 
> > fixup_topology(void) {
> >      if (has_big_core)
> >         powerpc_topology[smt_idx].mask = smallcore_smt_mask;
> > 
> >     if (shared_caches) {
> >        const char *name = "CACHE";
> >        powerpc_topology[bigcore_idx].mask = shared_cache_mask;
> >        strlcpy(powerpc_topology[bigcore_idx].name, name,
> >        				strlen(name));
> >        powerpc_topology[bigcore_idx].sd_flags = powerpc_shared_cache_flags;
> >     }
> > 
> >     /* Any other changes to the topology structure here */
> 
> We could do this.
> 
> > 
> > And also as an optimization, get rid of degenerate structures here
> > itself so that we don't pay additional penalty while building the
> > sched-domains each time.
> > 
> 
> Yes this is definitely in plan, but slightly later in time.
>

Ah, ok. Fine in that case.

> Thanks for the review and comments.
> 
> -- 
> Thanks and Regards
> Srikar Dronamraju

  reply	other threads:[~2020-07-20  9:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  4:36 [PATCH 00/11] Support for grouping cores Srikar Dronamraju
2020-07-14  4:36 ` [PATCH 01/11] powerpc/smp: Cache node for reuse Srikar Dronamraju
2020-07-17  4:51   ` Gautham R Shenoy
2020-07-14  4:36 ` [PATCH 02/11] powerpc/smp: Merge Power9 topology with Power topology Srikar Dronamraju
2020-07-17  5:44   ` Gautham R Shenoy
2020-07-20  8:10     ` Srikar Dronamraju
2020-07-14  4:36 ` [PATCH 03/11] powerpc/smp: Move powerpc_topology above Srikar Dronamraju
2020-07-17  5:45   ` Gautham R Shenoy
2020-07-14  4:36 ` [PATCH 04/11] powerpc/smp: Enable small core scheduling sooner Srikar Dronamraju
2020-07-17  5:48   ` Gautham R Shenoy
2020-07-20  7:20     ` Srikar Dronamraju
2020-07-20  7:47   ` Jordan Niethe
2020-07-20  8:52     ` Srikar Dronamraju
2020-07-14  4:36 ` [PATCH 05/11] powerpc/smp: Dont assume l2-cache to be superset of sibling Srikar Dronamraju
2020-07-14  5:40   ` Oliver O'Halloran
2020-07-14  6:30     ` Srikar Dronamraju
2020-07-17  6:00   ` Gautham R Shenoy
2020-07-20  6:45     ` Srikar Dronamraju
2020-07-20  8:58       ` Gautham R Shenoy
2020-07-14  4:36 ` [PATCH 06/11] powerpc/smp: Generalize 2nd sched domain Srikar Dronamraju
2020-07-17  6:37   ` Gautham R Shenoy
2020-07-20  6:19     ` Srikar Dronamraju
2020-07-20  9:07       ` Gautham R Shenoy [this message]
2020-07-14  4:36 ` [PATCH 07/11] Powerpc/numa: Detect support for coregroup Srikar Dronamraju
2020-07-17  8:08   ` Gautham R Shenoy
2020-07-20 13:56   ` Michael Ellerman
2020-07-21  2:57     ` Srikar Dronamraju
2020-07-14  4:36 ` [PATCH 08/11] powerpc/smp: Allocate cpumask only after searching thread group Srikar Dronamraju
2020-07-17  8:08   ` Gautham R Shenoy
2020-07-14  4:36 ` [PATCH 09/11] Powerpc/smp: Create coregroup domain Srikar Dronamraju
2020-07-17  8:19   ` Gautham R Shenoy
2020-07-17  8:23     ` Gautham R Shenoy
2020-07-20  6:02     ` Srikar Dronamraju
2020-07-14  4:36 ` [PATCH 10/11] powerpc/smp: Implement cpu_to_coregroup_id Srikar Dronamraju
2020-07-17  8:26   ` Gautham R Shenoy
2020-07-20  5:48     ` Srikar Dronamraju
2020-07-20  9:10       ` Gautham R Shenoy
2020-07-20 10:26         ` Srikar Dronamraju
2020-07-14  4:36 ` [PATCH 11/11] powerpc/smp: Provide an ability to disable coregroup Srikar Dronamraju
2020-07-17  8:28   ` Gautham R Shenoy
2020-07-20 13:57   ` Michael Ellerman
2020-07-14  5:06 ` [PATCH 00/11] Support for grouping cores 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=20200720090702.GB6680@in.ibm.com \
    --to=ego@linux.vnet.ibm.com \
    --cc=anton@au1.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=michaele@au1.ibm.com \
    --cc=mikey@linux.ibm.com \
    --cc=nathanl@linux.ibm.com \
    --cc=npiggin@au1.ibm.com \
    --cc=oliveroh@au1.ibm.com \
    --cc=srikar@linux.vnet.ibm.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.