Message ID | 20211105041132.1443767-1-npiggin@gmail.com (mailing list archive) |
---|---|
State | Changes Requested |
Headers | show |
Series | powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/github-powerpc_ppctests | success | Successfully ran 8 jobs. |
snowpatch_ozlabs/github-powerpc_selftests | success | Successfully ran 8 jobs. |
snowpatch_ozlabs/github-powerpc_clang | success | Successfully ran 7 jobs. |
snowpatch_ozlabs/github-powerpc_sparse | success | Successfully ran 4 jobs. |
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
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
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
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
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"
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(-)