Nicholas Piggin <npig...@gmail.com> writes: > 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.
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
