Re: [RFC][2.6.12.3] IRQ compression/sharing patch

[Andi Kleen]

On Thu, Aug 04, 2005 at 12:05:50AM -0700, James Cleverdon wrote:

> diff -pruN 2.6.12.3/arch/i386/kernel/acpi/boot.c n12.3/arch/i386/kernel/acpi/boot.c
> --- 2.6.12.3/arch/i386/kernel/acpi/boot.c	2005-07-15 14:18:57.000000000 -0700
> +++ n12.3/arch/i386/kernel/acpi/boot.c	2005-08-04 00:01:10.199710211 -0700
> @@ -42,6 +42,7 @@
>  static inline void  acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
>  extern void __init clustered_apic_check(void);
>  static inline int ioapic_setup_disabled(void) { return 0; }
> +extern int gsi_irq_sharing(int gsi);
>  #include <asm/proto.h>
>  
>  #else	/* X86 */
> @@ -51,6 +52,9 @@ static inline int ioapic_setup_disabled(
>  #include <mach_mpparse.h>
>  #endif	/* CONFIG_X86_LOCAL_APIC */
>  
> +static inline int gsi_irq_sharing(int gsi) { return gsi; }

Why is this different for i386/x86-64? It shouldn't.

As a unrelated note we really need to get rid of this whole ifdef block.

> +++ n12.3/arch/x86_64/Kconfig	2005-08-03 21:31:07.487451167 -0700
> @@ -280,13 +280,13 @@ config HAVE_DEC_LOCK
>  	default y
>  
>  config NR_CPUS
> -	int "Maximum number of CPUs (2-256)"
> -	range 2 256
> +	int "Maximum number of CPUs (2-255)"
> +	range 2 255
>  	depends on SMP
> -	default "8"
> +	default "16"

Don't change the default please.

> +static int next_irq = 16;

Won't this need a lock for hotplug later?

> +
> + retry_vector:
> +	vector = assign_irq_vector(gsi);
> +
> +	/*
> +	 * Sharing vectors means sharing IRQs, so scan irq_vectors for previous
> +	 * use of vector and if found, return that IRQ.  However, we never want
> +	 * to share legacy IRQs, which usually have a different trigger mode
> +	 * than PCI.
> +	 */

Can we perhaps force such sharing early temporarily even when the table
is not filled up?  This way we would get better test coverage of all
of  this.

That would be later disabled of course.

Rest looks ok to me.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/