Patchwork [5/5] powerpc: Increase NR_IRQS Kconfig maximum to 32768

login
register
mail settings
Submitter Anton Blanchard
Date Jan. 31, 2010, 11:14 a.m.
Message ID <20100131111403.GP2996@kryten>
Download mbox | patch
Permalink /patch/44109/
State Accepted, archived
Commit 859aefc5afc6c00dae630680e5470f7a2c27c4a0
Delegated to: Benjamin Herrenschmidt
Headers show

Comments

Anton Blanchard - Jan. 31, 2010, 11:14 a.m.
With dynamic irq descriptors the overhead of a large NR_IRQS is much lower
than it used to be. With more MSI-X capable adapters and drivers exploiting 
multiple vectors we may as well allow the user to increase it beyond the
current maximum of 512.

32768 seems large enough that we'd never have to bump it again (although I bet
my prediction is horribly wrong). It boot tests OK and the vmlinux footprint
increase is only around 500kB due to:

struct irq_map_entry irq_map[NR_IRQS];

We format /proc/interrupts correctly with the previous changes:

             CPU0       CPU1       CPU2       CPU3       CPU4       CPU5
  286:          0          0          0          0          0          0     
  516:          0          0          0          0          0          0     
16689:       1833          0          0          0          0          0     
17157:          0          0          0          0          0          0     
17158:        319          0          0          0          0          0     
25092:          0          0          0          0          0          0     

Signed-off-by: Anton Blanchard <anton@samba.org>
---
Benjamin Herrenschmidt - Jan. 31, 2010, 8:35 p.m.
On Sun, 2010-01-31 at 22:14 +1100, Anton Blanchard wrote:
> With dynamic irq descriptors the overhead of a large NR_IRQS is much lower
> than it used to be. With more MSI-X capable adapters and drivers exploiting 
> multiple vectors we may as well allow the user to increase it beyond the
> current maximum of 512.
> 
> 32768 seems large enough that we'd never have to bump it again (although I bet
> my prediction is horribly wrong). It boot tests OK and the vmlinux footprint
> increase is only around 500kB due to:
> 
> struct irq_map_entry irq_map[NR_IRQS];

We could dynamically allocate that one.

Cheers,
Ben.

> We format /proc/interrupts correctly with the previous changes:
> 
>              CPU0       CPU1       CPU2       CPU3       CPU4       CPU5
>   286:          0          0          0          0          0          0     
>   516:          0          0          0          0          0          0     
> 16689:       1833          0          0          0          0          0     
> 17157:          0          0          0          0          0          0     
> 17158:        319          0          0          0          0          0     
> 25092:          0          0          0          0          0          0     
> 
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
> 
> Index: linux-cpumask/arch/powerpc/Kconfig
> ===================================================================
> --- linux-cpumask.orig/arch/powerpc/Kconfig	2010-01-31 15:07:11.707211107 +1100
> +++ linux-cpumask/arch/powerpc/Kconfig	2010-01-31 21:52:39.999711689 +1100
> @@ -58,7 +58,7 @@ config IRQ_PER_CPU
>  
>  config NR_IRQS
>  	int "Number of virtual interrupt numbers"
> -	range 32 512
> +	range 32 32768
>  	default "512"
>  	help
>  	  This defines the number of virtual interrupt numbers the kernel
Gabriel Paubert - Feb. 1, 2010, 9:09 a.m.
On Sun, Jan 31, 2010 at 10:14:03PM +1100, Anton Blanchard wrote:
> 
> With dynamic irq descriptors the overhead of a large NR_IRQS is much lower
> than it used to be. With more MSI-X capable adapters and drivers exploiting 
> multiple vectors we may as well allow the user to increase it beyond the
> current maximum of 512.
> 
> 32768 seems large enough that we'd never have to bump it again (although I bet
> my prediction is horribly wrong). It boot tests OK and the vmlinux footprint
> increase is only around 500kB due to:

Only 1/2 MB? 

I'm running Linux on 12 year old PPC machines which have 16MB
or RAM (ok, they are still running an old kernel, but a few
patches like this and they wont't even boot). The kernels
I have are well below 1MB, code+data+bss. 

Yes it is configurable, thanks, and 64 is enough for these
machines (8259 plus an MPIC), so it's not that crucial.

What I object to is calling 1/2MB negligible.

	Gabriel
Benjamin Herrenschmidt - Feb. 1, 2010, 10:04 a.m.
On Mon, 2010-02-01 at 10:09 +0100, Gabriel Paubert wrote:
> On Sun, Jan 31, 2010 at 10:14:03PM +1100, Anton Blanchard wrote:
> > 
> > With dynamic irq descriptors the overhead of a large NR_IRQS is much lower
> > than it used to be. With more MSI-X capable adapters and drivers exploiting 
> > multiple vectors we may as well allow the user to increase it beyond the
> > current maximum of 512.
> > 
> > 32768 seems large enough that we'd never have to bump it again (although I bet
> > my prediction is horribly wrong). It boot tests OK and the vmlinux footprint
> > increase is only around 500kB due to:
> 
> Only 1/2 MB? 
> 
> I'm running Linux on 12 year old PPC machines which have 16MB
> or RAM (ok, they are still running an old kernel, but a few
> patches like this and they wont't even boot). The kernels
> I have are well below 1MB, code+data+bss. 
> 
> Yes it is configurable, thanks, and 64 is enough for these
> machines (8259 plus an MPIC), so it's not that crucial.
> 
> What I object to is calling 1/2MB negligible.

Yeah well, all Anton did was to push up the -max- value you can set in
the config, not the default :-)

But yeah, it's not "negligible" per-se.

Cheers,
Ben.

Patch

Index: linux-cpumask/arch/powerpc/Kconfig
===================================================================
--- linux-cpumask.orig/arch/powerpc/Kconfig	2010-01-31 15:07:11.707211107 +1100
+++ linux-cpumask/arch/powerpc/Kconfig	2010-01-31 21:52:39.999711689 +1100
@@ -58,7 +58,7 @@  config IRQ_PER_CPU
 
 config NR_IRQS
 	int "Number of virtual interrupt numbers"
-	range 32 512
+	range 32 32768
 	default "512"
 	help
 	  This defines the number of virtual interrupt numbers the kernel