[PATCH v2 07/13] powerpc: Increase NR_IRQS range to support more KVM guests

Michael Ellerman mpe at ellerman.id.au
Wed Dec 16 13:49:01 AEDT 2020


Cédric Le Goater <clg at kaod.org> writes:
> On 12/11/20 12:51 AM, Michael Ellerman wrote:
>> Cédric Le Goater <clg at kaod.org> writes:
>>> PowerNV systems can handle up to 4K guests and 1M interrupt numbers
>>> per chip. Increase the range of allowed interrupts to support a larger
>>> number of guests.
>>>
>>> Reviewed-by: Greg Kurz <groug at kaod.org>
>>> Signed-off-by: Cédric Le Goater <clg at kaod.org>
>>> ---
>>>  arch/powerpc/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index 5181872f9452..c250fbd430d1 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -66,7 +66,7 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK
>>>  
>>>  config NR_IRQS
>>>  	int "Number of virtual interrupt numbers"
>>> -	range 32 32768
>>> +	range 32 1048576
>>>  	default "512"
>>>  	help
>>>  	  This defines the number of virtual interrupt numbers the kernel
>> 
>> We should really do what other arches do, and size this appropriately
>> based on the config, rather than asking users to guess what size they
>> need.
>> 
>> But I guess I'll take this for now, and we can do something fancier
>> later.
>
> I was thinking on adding a property to OPAL to size the HW interrupt 
> number space. Is that it ?

That's a separate issue. NR_IRQS is about the maximum number of Linux
interrupts, and it's a compile time limit.

In the old days there was an array of irq_desc[NR_IRQS] in .data, so you
didn't want NR_IRQS to be too big. These days we don't do that, because
of the sparse IRQ support, but I don't know if it's completely free to
make NR_IRQS arbitrarily large at build time.

> That would be good because it's increasing from 20bits on P9 to 24bits
> on P10.

That's probably still helpful, it might mean we can shrink some
structures at runtime.

> I am checking other arches.

Thanks.

cheers


More information about the Linuxppc-dev mailing list