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 05/11] powerpc/smp: Dont assume l2-cache to be superset of sibling
Date: Mon, 20 Jul 2020 14:28:12 +0530	[thread overview]
Message-ID: <20200720085812.GA6680@in.ibm.com> (raw)
In-Reply-To: <20200720064504.GD21103@linux.vnet.ibm.com>

Hi Srikar,

On Mon, Jul 20, 2020 at 12:15:04PM +0530, Srikar Dronamraju wrote:
> * Gautham R Shenoy <ego@linux.vnet.ibm.com> [2020-07-17 11:30:11]:
> 
> > Hi Srikar,
> > 
> > On Tue, Jul 14, 2020 at 10:06:18AM +0530, Srikar Dronamraju wrote:
> > > Current code assumes that cpumask of cpus sharing a l2-cache mask will
> > > always be a superset of cpu_sibling_mask.
> > > 
> > > Lets stop that assumption.
> > > 
> > > 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>
> > > ---
> > >  arch/powerpc/kernel/smp.c | 28 +++++++++++++++-------------
> > >  1 file changed, 15 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> > > index 7d430fc536cc..875f57e41355 100644
> > > --- a/arch/powerpc/kernel/smp.c
> > > +++ b/arch/powerpc/kernel/smp.c
> > > @@ -1198,6 +1198,7 @@ static bool update_mask_by_l2(int cpu, struct cpumask *(*mask_fn)(int))
> > >  	struct device_node *l2_cache, *np;
> > >  	int i;
> > > 
> > > +	cpumask_set_cpu(cpu, mask_fn(cpu));
> > 
> > It would be good to comment why do we need to do set the CPU in the
> > l2-mask if we don't have a l2cache domain.
> > 
> 
> Good Catch, 
> We should move this after the cpu_to_l2cache.
> 
> > >  	l2_cache = cpu_to_l2cache(cpu);
> > >  	if (!l2_cache)
> > >  		return false;
> > > @@ -1284,29 +1285,30 @@ static void add_cpu_to_masks(int cpu)
> > >  	 * add it to it's own thread sibling mask.
> > >  	 */
> > >  	cpumask_set_cpu(cpu, cpu_sibling_mask(cpu));
> > > +	cpumask_set_cpu(cpu, cpu_core_mask(cpu));
> > > 
> > >  	for (i = first_thread; i < first_thread + threads_per_core; i++)
> > >  		if (cpu_online(i))
> > >  			set_cpus_related(i, cpu, cpu_sibling_mask);
> > > 
> > >  	add_cpu_to_smallcore_masks(cpu);
> > > -	/*
> > > -	 * Copy the thread sibling mask into the cache sibling mask
> > > -	 * and mark any CPUs that share an L2 with this CPU.
> > > -	 */
> > > -	for_each_cpu(i, cpu_sibling_mask(cpu))
> > > -		set_cpus_related(cpu, i, cpu_l2_cache_mask);
> > >  	update_mask_by_l2(cpu, cpu_l2_cache_mask);
> > > 
> > > -	/*
> > > -	 * Copy the cache sibling mask into core sibling mask and mark
> > > -	 * any CPUs on the same chip as this CPU.
> > > -	 */
> > > -	for_each_cpu(i, cpu_l2_cache_mask(cpu))
> > > -		set_cpus_related(cpu, i, cpu_core_mask);
> > > +	if (pkg_id == -1) {
> > > +		struct cpumask *(*mask)(int) = cpu_sibling_mask;
> > > +
> > > +		/*
> > > +		 * Copy the sibling mask into core sibling mask and
> > > +		 * mark any CPUs on the same chip as this CPU.
> > > +		 */
> > > +		if (shared_caches)
> > > +			mask = cpu_l2_cache_mask;
> > > +
> > 
> > 
> > Now that we decoupling the containment relationship between
> > sibling_mask and l2-cache mask, should we set all the CPUs that are
> > both in cpu_sibling_mask(cpu) as well as cpu_l2_mask(cpu) in
> > cpu_core_mask ? 
> > 
> 
> Are you saying instead of setting this cpu in this cpu_core_mask, can we set
> all the cpus in the mask in cpu_core_mask?

No. What I am referring to is in the for-loop below, you are setting
the CPUs that are set in mask(cpu) in the cpu_core_mask.

Now, the above code sets
mask(cpu) == cpu_sibling_mask(cpu) in the absence of shared_caches, and 
          == cpu_l2_cache_mask(cpu) in the presence of shared_cache.

Since we have decoupled the assumption that cpu_sibling_mask(cpu) may not
be contained within cpu_l2_cache_mask(cpu), in the presence of a
shared-cache, why are we only picking the CPUs in
cpu_l2_cache_mask(cpu) to be set in cpu_core_maks(cpu) ? It should
ideally be the superset whose CPUs should be set in
cpu_core_mask(cpu). And the correct cpuset is
cpumask_or(cpu_sibling_mask(cpu), cpu_l2_cache_mask(cpu))


> Currently we dont know if any of the cpus of the mask were already set or
> not. Plus we need to anyway update cpumask of all other cpus to says they
> are related. So setting a mask instead of cpu at a time will not change
> anything for our side.
> 
> > > +		for_each_cpu(i, mask(cpu))
> > > +			set_cpus_related(cpu, i, cpu_core_mask);
> > > 
> > > -	if (pkg_id == -1)
> > >  		return;
> > > +	}
> > > 
> > >  	for_each_cpu(i, cpu_online_mask)
> > >  		if (get_physical_package_id(i) == pkg_id)
> > > -- 
> > > 2.17.1
> > > 
> > --
> > Thanks and Regards
> > gautham.
> 
> -- 
> Thanks and Regards
> Srikar Dronamraju

  reply	other threads:[~2020-07-20  9:00 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 [this message]
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
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=20200720085812.GA6680@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.