[PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[Nicholas Piggin]

Similarly to x86, add MAXSMP that should help flush out problems with
vary large SMP and other values associated with very big systems.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
 arch/powerpc/Kconfig                   | 8 ++++++++
 arch/powerpc/platforms/Kconfig.cputype | 5 +++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b8f6185d3998..d585fcfa456f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -64,6 +64,13 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 config NEED_PER_CPU_PAGE_FIRST_CHUNK
 	def_bool y if PPC64
 
+config MAXSMP
+	bool "Enable Maximum number of SMP Processors and NUMA Nodes"
+	depends on SMP && DEBUG_KERNEL && PPC_BOOK3S_64
+	help
+	  Enable maximum number of CPUS and NUMA Nodes for this architecture.
+	  If unsure, say N.
+
 config NR_IRQS
 	int "Number of virtual interrupt numbers"
 	range 32 1048576
@@ -666,6 +673,7 @@ config NUMA
 
 config NODES_SHIFT
 	int
+	default "10" if MAXSMP
 	default "8" if PPC64
 	default "4"
 	depends on NUMA
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index a208997ade88..3fd6c1941151 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -476,8 +476,9 @@ config SMP
 	  If you don't know what to do here, say N.
 
 config NR_CPUS
-	int "Maximum number of CPUs (2-8192)" if SMP
-	range 2 8192 if SMP
+	int "Maximum number of CPUs (2-8192)" if SMP && !MAXSMP
+	range 2 16384 if SMP
+	default 16384 if MAXSMP
 	default "1" if !SMP
 	default "32" if PPC64
 	default "4"
-- 
2.23.0

Re: [PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 7688 bytes --]

Hi Nicholas,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.15 next-20211105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-introduce-CONFIG_MAXSMP-to-test-very-large-SMP/20211105-121250
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/9ca640e0639b6bdab803c15ba0ea3321a846c466
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Nicholas-Piggin/powerpc-64s-introduce-CONFIG_MAXSMP-to-test-very-large-SMP/20211105-121250
        git checkout 9ca640e0639b6bdab803c15ba0ea3321a846c466
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/cpufreq/cpufreq_ondemand.c: In function 'od_set_powersave_bias':
>> drivers/cpufreq/cpufreq_ondemand.c:446:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
     446 | }
         | ^
   cc1: all warnings being treated as errors
--
   kernel/trace/preemptirq_delay_test.c: In function 'preemptirq_delay_run':
>> kernel/trace/preemptirq_delay_test.c:145:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
     145 | }
         | ^
   cc1: all warnings being treated as errors
--
   drivers/powercap/dtpm_cpu.c: In function 'set_pd_power_limit':
>> drivers/powercap/dtpm_cpu.c:104:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
     104 | }
         | ^
   drivers/powercap/dtpm_cpu.c: In function 'get_pd_power_uw':
   drivers/powercap/dtpm_cpu.c:129:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
     129 | }
         | ^
   cc1: all warnings being treated as errors
--
   In file included from <command-line>:
   drivers/leds/trigger/ledtrig-cpu.c: In function 'ledtrig_cpu_init':
>> include/linux/compiler_types.h:322:45: error: call to '__compiletime_assert_175' declared with attribute error: BUILD_BUG_ON failed: CONFIG_NR_CPUS > 9999
     322 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
         |                                             ^
   include/linux/compiler_types.h:303:25: note: in definition of macro '__compiletime_assert'
     303 |                         prefix ## suffix();                             \
         |                         ^~~~~~
   include/linux/compiler_types.h:322:9: note: in expansion of macro '_compiletime_assert'
     322 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
         |         ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
         |                                     ^~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:50:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
      50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
         |         ^~~~~~~~~~~~~~~~
   drivers/leds/trigger/ledtrig-cpu.c:137:9: note: in expansion of macro 'BUILD_BUG_ON'
     137 |         BUILD_BUG_ON(CONFIG_NR_CPUS > 9999);
         |         ^~~~~~~~~~~~
--
   drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c: In function 'update_xps.isra':
>> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:2495:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
    2495 | }
         | ^
   cc1: all warnings being treated as errors
--
   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_request_irq_multi_msi':
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3554:1: error: the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
    3554 | }
         | ^
   cc1: all warnings being treated as errors


vim +446 drivers/cpufreq/cpufreq_ondemand.c

af926185231a6e3 Rafael J. Wysocki         2016-02-05  412  
fb30809efa3edeb Jacob Shin                2013-04-02  413  static void od_set_powersave_bias(unsigned int powersave_bias)
fb30809efa3edeb Jacob Shin                2013-04-02  414  {
fb30809efa3edeb Jacob Shin                2013-04-02  415  	unsigned int cpu;
fb30809efa3edeb Jacob Shin                2013-04-02  416  	cpumask_t done;
fb30809efa3edeb Jacob Shin                2013-04-02  417  
c28375583b6471c Jacob Shin                2013-06-25  418  	default_powersave_bias = powersave_bias;
fb30809efa3edeb Jacob Shin                2013-04-02  419  	cpumask_clear(&done);
fb30809efa3edeb Jacob Shin                2013-04-02  420  
09681a0772f773d Sebastian Andrzej Siewior 2021-08-03  421  	cpus_read_lock();
fb30809efa3edeb Jacob Shin                2013-04-02  422  	for_each_online_cpu(cpu) {
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  423  		struct cpufreq_policy *policy;
e40e7b255e591d0 Rafael J. Wysocki         2016-02-10  424  		struct policy_dbs_info *policy_dbs;
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  425  		struct dbs_data *dbs_data;
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  426  		struct od_dbs_tuners *od_tuners;
44152cb82d1ad6a Viresh Kumar              2015-07-18  427  
fb30809efa3edeb Jacob Shin                2013-04-02  428  		if (cpumask_test_cpu(cpu, &done))
fb30809efa3edeb Jacob Shin                2013-04-02  429  			continue;
fb30809efa3edeb Jacob Shin                2013-04-02  430  
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  431  		policy = cpufreq_cpu_get_raw(cpu);
10dd8573b09e84b Quentin Perret            2020-06-29  432  		if (!policy || policy->governor != &CPU_FREQ_GOV_ONDEMAND)
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  433  			continue;
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  434  
8c8f77fd0719a07 Rafael J. Wysocki         2016-02-21  435  		policy_dbs = policy->governor_data;
e40e7b255e591d0 Rafael J. Wysocki         2016-02-10  436  		if (!policy_dbs)
c28375583b6471c Jacob Shin                2013-06-25  437  			continue;
fb30809efa3edeb Jacob Shin                2013-04-02  438  
fb30809efa3edeb Jacob Shin                2013-04-02  439  		cpumask_or(&done, &done, policy->cpus);
c28375583b6471c Jacob Shin                2013-06-25  440  
bc505475b85de9a Rafael J. Wysocki         2016-02-07  441  		dbs_data = policy_dbs->dbs_data;
c28375583b6471c Jacob Shin                2013-06-25  442  		od_tuners = dbs_data->tuners;
c28375583b6471c Jacob Shin                2013-06-25  443  		od_tuners->powersave_bias = default_powersave_bias;
fb30809efa3edeb Jacob Shin                2013-04-02  444  	}
09681a0772f773d Sebastian Andrzej Siewior 2021-08-03  445  	cpus_read_unlock();
fb30809efa3edeb Jacob Shin                2013-04-02 @446  }
fb30809efa3edeb Jacob Shin                2013-04-02  447  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 72217 bytes --]

Re: [PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[Michael Ellerman]

Nicholas Piggin <npiggin@gmail.com> writes:
> Similarly to x86, add MAXSMP that should help flush out problems with
> vary large SMP and other values associated with very big systems.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
>  arch/powerpc/Kconfig                   | 8 ++++++++
>  arch/powerpc/platforms/Kconfig.cputype | 5 +++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b8f6185d3998..d585fcfa456f 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -64,6 +64,13 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>  config NEED_PER_CPU_PAGE_FIRST_CHUNK
>  	def_bool y if PPC64
>  
> +config MAXSMP
> +	bool "Enable Maximum number of SMP Processors and NUMA Nodes"
> +	depends on SMP && DEBUG_KERNEL && PPC_BOOK3S_64
> +	help
> +	  Enable maximum number of CPUS and NUMA Nodes for this architecture.
> +	  If unsure, say N.

As evidenced by the kernel robot report, I think we need to exclude this
from allyesconfig.

Because our max is 16K, larger than the 8K on x86, we are going to be
constantly hitting stack usage errors in driver code. Getting those
fixed tends to take time, because the driver authors don't see the
warnings when they build for other arches, and because the fixes go via
driver trees.

Making MAXSMP depend on !COMPILE_TEST should do the trick.

cheers

Re: [PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[Nicholas Piggin]

Excerpts from Michael Ellerman's message of November 8, 2021 3:28 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> Similarly to x86, add MAXSMP that should help flush out problems with
>> vary large SMP and other values associated with very big systems.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>>  arch/powerpc/Kconfig                   | 8 ++++++++
>>  arch/powerpc/platforms/Kconfig.cputype | 5 +++--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index b8f6185d3998..d585fcfa456f 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -64,6 +64,13 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>  config NEED_PER_CPU_PAGE_FIRST_CHUNK
>>  	def_bool y if PPC64
>>  
>> +config MAXSMP
>> +	bool "Enable Maximum number of SMP Processors and NUMA Nodes"
>> +	depends on SMP && DEBUG_KERNEL && PPC_BOOK3S_64
>> +	help
>> +	  Enable maximum number of CPUS and NUMA Nodes for this architecture.
>> +	  If unsure, say N.
> 
> As evidenced by the kernel robot report, I think we need to exclude this
> from allyesconfig.
> 
> Because our max is 16K, larger than the 8K on x86, we are going to be
> constantly hitting stack usage errors in driver code. Getting those
> fixed tends to take time, because the driver authors don't see the
> warnings when they build for other arches, and because the fixes go via
> driver trees.

Yeah I realised after I hit send. Surprisingly there weren't too many
but agree going ahead of x86 would always come with annoyances and at
least would have to fix existing tree.

> Making MAXSMP depend on !COMPILE_TEST should do the trick.

I'll do that. Or maybe make it 8192 if COMPILE_TEST otherwise 16384.

The reason for 16K is if we bump the deault at some point we might go to 
8K, in which case it would be good to have a test above it to catch
marginal cases.

Thanks,
Nick

Re: [PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[Michael Ellerman]

Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Michael Ellerman's message of November 8, 2021 3:28 pm:
>> Nicholas Piggin <npiggin@gmail.com> writes:
>>> Similarly to x86, add MAXSMP that should help flush out problems with
>>> vary large SMP and other values associated with very big systems.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>>  arch/powerpc/Kconfig                   | 8 ++++++++
>>>  arch/powerpc/platforms/Kconfig.cputype | 5 +++--
>>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index b8f6185d3998..d585fcfa456f 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -64,6 +64,13 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>>  config NEED_PER_CPU_PAGE_FIRST_CHUNK
>>>  	def_bool y if PPC64
>>>  
>>> +config MAXSMP
>>> +	bool "Enable Maximum number of SMP Processors and NUMA Nodes"
>>> +	depends on SMP && DEBUG_KERNEL && PPC_BOOK3S_64
>>> +	help
>>> +	  Enable maximum number of CPUS and NUMA Nodes for this architecture.
>>> +	  If unsure, say N.
>> 
>> As evidenced by the kernel robot report, I think we need to exclude this
>> from allyesconfig.
>> 
>> Because our max is 16K, larger than the 8K on x86, we are going to be
>> constantly hitting stack usage errors in driver code. Getting those
>> fixed tends to take time, because the driver authors don't see the
>> warnings when they build for other arches, and because the fixes go via
>> driver trees.
>
> Yeah I realised after I hit send. Surprisingly there weren't too many
> but agree going ahead of x86 would always come with annoyances and at
> least would have to fix existing tree.
>
>> Making MAXSMP depend on !COMPILE_TEST should do the trick.
>
> I'll do that. Or maybe make it 8192 if COMPILE_TEST otherwise 16384.

Yeah that could be OK.

> The reason for 16K is if we bump the deault at some point we might go to 
> 8K, in which case it would be good to have a test above it to catch
> marginal cases.

Yeah makes sense to have some head room.

cheers