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
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 <redacted>
All errors (new ones prefixed by >>):
drivers/cpufreq/cpufreq_ondemand.c: In function 'od_set_powersave_bias':quoted
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':quoted
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':quoted
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':quoted
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':quoted
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':quoted
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 [off-list ref] writes:
quoted hunk
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 [off-list ref] writes:
quoted
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 [off-list ref] writes:
Excerpts from Michael Ellerman's message of November 8, 2021 3:28 pm:
quoted
Nicholas Piggin [off-list ref] writes:
quoted
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.
quoted
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