Excerpts from Michael Ellerman's message of November 8, 2021 3:28 pm: > Nicholas Piggin <npig...@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 <npig...@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
