Re: [PATCH v2 02/10] powerpc/smp: Merge Power9 topology with Power topology

From: Gautham R Shenoy
Date: Wed Jul 22 2020 - 01:48:46 EST


On Tue, Jul 21, 2020 at 05:08:06PM +0530, Srikar Dronamraju wrote:
> A new sched_domain_topology_level was added just for Power9. However the
> same can be achieved by merging powerpc_topology with power9_topology
> and makes the code more simpler especially when adding a new sched
> domain.
>
> Cc: linuxppc-dev <linuxppc-dev@xxxxxxxxxxxxxxxx>
> Cc: LKML <linux-kernel@xxxxxxxxxxxxxxx>
> Cc: Michael Ellerman <michaele@xxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Valentin Schneider <valentin.schneider@xxxxxxx>
> Cc: Nick Piggin <npiggin@xxxxxxxxxxx>
> Cc: Oliver OHalloran <oliveroh@xxxxxxxxxxx>
> Cc: Nathan Lynch <nathanl@xxxxxxxxxxxxx>
> Cc: Michael Neuling <mikey@xxxxxxxxxxxxx>
> Cc: Anton Blanchard <anton@xxxxxxxxxxx>
> Cc: Gautham R Shenoy <ego@xxxxxxxxxxxxxxxxxx>
> Cc: Vaidyanathan Srinivasan <svaidy@xxxxxxxxxxxxx>
> Cc: Jordan Niethe <jniethe5@xxxxxxxxx>
> Signed-off-by: Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx>
> ---
> Changelog v1 -> v2:
> powerpc/smp: Merge Power9 topology with Power topology
> Replaced a reference to cpu_smt_mask with per_cpu(cpu_sibling_map, cpu)
> since cpu_smt_mask is only defined under CONFIG_SCHED_SMT
>
> arch/powerpc/kernel/smp.c | 33 ++++++++++-----------------------
> 1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 680c0edcc59d..0e0b118d9b6e 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1315,7 +1315,7 @@ int setup_profiling_timer(unsigned int multiplier)
> }
>
> #ifdef CONFIG_SCHED_SMT
> -/* cpumask of CPUs with asymetric SMT dependancy */
> +/* cpumask of CPUs with asymmetric SMT dependency */
> static int powerpc_smt_flags(void)
> {
> int flags = SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES;
> @@ -1328,14 +1328,6 @@ static int powerpc_smt_flags(void)
> }
> #endif
>
> -static struct sched_domain_topology_level powerpc_topology[] = {
> -#ifdef CONFIG_SCHED_SMT
> - { cpu_smt_mask, powerpc_smt_flags, SD_INIT_NAME(SMT) },
> -#endif
> - { cpu_cpu_mask, SD_INIT_NAME(DIE) },
> - { NULL, },
> -};
> -
> /*
> * P9 has a slightly odd architecture where pairs of cores share an L2 cache.
> * This topology makes it *much* cheaper to migrate tasks between adjacent cores
> @@ -1353,7 +1345,13 @@ static int powerpc_shared_cache_flags(void)
> */
> static const struct cpumask *shared_cache_mask(int cpu)
> {
> - return cpu_l2_cache_mask(cpu);
> + if (shared_caches)
> + return cpu_l2_cache_mask(cpu);
> +
> + if (has_big_cores)
> + return cpu_smallcore_mask(cpu);
> +
> + return per_cpu(cpu_sibling_map, cpu);
> }


It might be helpful to enumerate the consequences of this change:

With this patch, on POWER7 and POWER8

SMT and CACHE domains' cpumasks will both be
per_cpu(cpu_sibling_map, cpu).

On POWER7 SMT level flags has the following
(SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES | SD_ASYM_PACKING)

On POWER8 SMT level flags has the following
(SD_SHARE_CPUCAPACITY | SD_SHARE_PKG_RESOURCES).

On both POWER7 and POWER8, CACHE level flags only has
SD_SHARE_PKG_RESOURCES

Thus, on both POWER7 and POWER8, since the SMT and CACHE cpumasks
are the same and since CACHE has no additional flags which SMT does
not, the parent domain CACHE will be degenerated.

Hence we will have SMT --> DIE --> NUMA as before without the
patch. So the patch introduces no behavioural change. Only change
is an additional degeneration of the CACHE domain.

On POWER9 : Baremetal.
SMT level cpumask = per_cpu(cpu_sibling_map, cpu)

Since the caches are shared for a pair of two cores,
CACHE level cpumask = cpu_l2_cache_mask(cpu)

Thus, we will have SMT --> CACHE --> DIE --> NUMA as before. No
behavioural change.

On POWER9 : LPAR
SMT level cpumask = cpu_smallcore_mask(cpu).

Since the caches are shared,
CACHE level cpumask = cpu_l2_cache_mask(cpu).

Thus, we will have SMT --> CACHE --> DIE --> NUMA as before. Again
no change in behaviour.

Reviewed-by: Gautham R. Shenoy <ego@xxxxxxxxxxxxxxxxxx>

--
Thanks and Regards
gautham.