[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 at 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 at 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