2.6.1-mm2: Get irq_vector size right for generic subarch UP installer kernels
PATCH 1/1 2.6.1-mm2: Get irq_vector size right for generic subarch UP installer kernels
Problem: Earlier I didn't consider the case of the generic sub-arch and uni-proc installer kernels used by a number of distros. It currently is scaled by NR_CPUS. The correct values should be big for summit and generic, and can stay the same for all others.
diff -pru 2.6.1-mm2/include/asm-i386/mach-default/irq_vectors.h t1mm2/include/asm-i386/mach-default/irq_vectors.h
--- 2.6.1-mm2/include/asm-i386/mach-default/irq_vectors.h 2004-01-08
22:59:19.000000000 -0800
+++ t1mm2/include/asm-i386/mach-default/irq_vectors.h 2004-01-13
13:43:56.000000000 -0800
@@ -90,8 +90,12 @@
#else
#ifdef CONFIG_X86_IO_APIC
#define NR_IRQS 224
-# if (224 >= 32 * NR_CPUS)
-# define NR_IRQ_VECTORS NR_IRQS
+/*
+ * For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs,
+ * even with uni-proc kernels, so use a big array.
+ */
+# if defined(CONFIG_X86_SUMMIT) || defined(CONFIG_X86_GENERICARCH) +# define NR_IRQ_VECTORS 1024
# else # define NR_IRQ_VECTORS (32 * NR_CPUS) # endif
include/asm-i386/mach-default/irq_vectors.h +6 -2
@@ -90,8 +90,12 @@#else #ifdef CONFIG_X86_IO_APIC #define NR_IRQS 224 -# if (224 >=32 *NR_CPUS ) -# define NR_IRQ_VECTORS NR_IRQS +/* +* For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs, +* even with uni-proc kernels, so use a big array. +*/ +# if defined(CONFIG_X86_SUMMIT ) || defined(CONFIG_X86_GENERICARCH ) +# define NR_IRQ_VECTORS 1024# else # define NR_IRQ_VECTORS (32 * NR_CPUS)# endif
Quoted 4 lines · James Cleverdon
Problem: Earlier I didn't consider the case of the generic sub-arch and uni-proc installer kernels used by a number of distros. It currently is scaled by
NR_CPUS. The correct values should be big for summit and generic, and can stay the same for all others.
This all looks strange, especially in assign_irq_vector() does this mean that you'll try and allocate up to 1024 vectors?
Quoted 11 lines
diff -pru
2.6.1-mm2/include/asm-i386/mach-default/irq_vectors.ht1mm2/include/asm-i386/mach-default/irq_vectors.h
---2.6.1-mm2/include/asm-i386/mach-default/irq_vectors.h2004-01-08
22:59:19.000000000 -0800
+++t1mm2/include/asm-i386/mach-default/irq_vectors.h2004-01-13
13:43:56.000000000 -0800(quoted diff) +0
-1@@ -90,8 +90,12 @@ #else #ifdef CONFIG_X86_IO_APIC #define NR_IRQS 224 -# if (224 >= 32 * NR_CPUS)
Review line 101
Quoted 10 lines
(quoted diff) +6
-1-# define NR_IRQ_VECTORS NR_IRQS +/* + * For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs, + * even with uni-proc kernels, so use a big array. + */ +# if defined(CONFIG_X86_SUMMIT) || defined(CONFIG_X86_GENERICARCH) +# define NR_IRQ_VECTORS 1024 # else # define NR_IRQ_VECTORS (32 * NR_CPUS) # endif
include/asm-i386/mach-default/irq_vectors.h +6 -2
@@ -90,8 +90,12 @@#else #ifdef CONFIG_X86_IO_APIC #define NR_IRQS 224 -# if (224 >=32 *NR_CPUS ) -# define NR_IRQ_VECTORS NR_IRQS +/* +* For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs, +* even with uni-proc kernels, so use a big array. +*/ +# if defined(CONFIG_X86_SUMMIT ) || defined(CONFIG_X86_GENERICARCH ) +# define NR_IRQ_VECTORS 1024# else # define NR_IRQ_VECTORS (32 * NR_CPUS)# endif
Quoted 8 lines · Zwane Mwaikambo
Quoted 4 lines · James Cleverdon
Problem: Earlier I didn't consider the case of the generic sub-arch and uni-proc installer kernels used by a number of distros. It currently is scaled by
NR_CPUS. The correct values should be big for summit and generic, and can stay the same for all others.This all looks strange, especially in
assign_irq_vector()does this mean that you'll try and allocate up to 1024 vectors?
The irq_vector array name is a bit misleading. It contains the vectors for each potential I/O APIC RTE. The array needs to be at least the sum of all the RTEs in the system. Summit PCI bridge chips have large I/O APICs (50 RTEs), and a large system has up to 16 of them. 16*50 = 800. Allocating 1k entries provides a pad for the future, and u8 doesn't cost much.
Quoted 21 lines
Quoted 21 lines
diff -pru
2.6.1-mm2/include/asm-i386/mach-default/irq_vectors.ht1mm2/include/asm-i386/mach-default/irq_vectors.h
---2.6.1-mm2/include/asm-i386/mach-default/irq_vectors.h2004-01-08
22:59:19.000000000 -0800
+++t1mm2/include/asm-i386/mach-default/irq_vectors.h2004-01-13
13:43:56.000000000 -0800include/asm-i386/mach-default/irq_vectors.h +2
-2@@ -90,8 +90,12 @@#else #ifdef CONFIG_X86_IO_APIC #define NR_IRQS 224 -# if (224 >=32 *NR_CPUS ) -# define NR_IRQ_VECTORS NR_IRQS +/* +* For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs, + * even with uni-proc kernels, so use a big array.
+ */include/asm-i386/mach-default/irq_vectors.h +2
-0+# if defined(CONFIG_X86_SUMMIT ) || defined(CONFIG_X86_GENERICARCH ) +# define NR_IRQ_VECTORS 1024# else # define NR_IRQ_VECTORS (32 * NR_CPUS)# endif
Signature · 3 lines
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot commQuoted 7 lines · James Cleverdon
Quoted 6 lines · Zwane Mwaikambo
Quoted 4 lines · James Cleverdon
Problem: Earlier I didn't consider the case of the generic sub-arch and uni-proc installer kernels used by a number of distros. It currently is scaled by
NR_CPUS. The correct values should be big for summit and generic, and can stay the same for all others.
Quoted 8 lines
Quoted 2 lines
This all looks strange, especially in
assign_irq_vector()does this mean that you'll try and allocate up to 1024 vectors?The
irq_vectorarray name is a bit misleading. It contains the vectors for each potential I/O APIC RTE. The array needs to be at least the sum of all the RTEs in the system. Summit PCI bridge chips have large I/O APICs (50 RTEs), and a large system has up to 16 of them. 16*50 = 800. Allocating 1k entries provides a pad for the future, and u8 doesn't cost much.
Ok i understand the need to accomodate all the RTEs, but what i was considering was what happens when assign_irq_vector runs out of vectors to allocate and ends up "wrapping". I just sent an email to Jun Nakajima with a bit more detail.
Thanks,
Zwane