[PATCH] powerpc/64s: introduce CONFIG_MAXSMP to test very large SMP

[Michael Ellerman]

Nicholas Piggin <npiggin at gmail.com> writes:
> 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.

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