linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	"Natalie Protasevich" <protasnb@gmail.com>,
	Andi Kleen <ak@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] i386 IOAPIC: de-fang IRQ compression
Date: Wed, 28 Nov 2007 01:21:18 -0500	[thread overview]
Message-ID: <200711280121.18376.lenb@kernel.org> (raw)

    commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
    (x86: avoid wasting IRQs for PCI devices)
    created a concept of "IRQ compression" on i386
    to conserve IRQ numbers on systems with many
    sparsely populated IO APICs.
    
    The same scheme was also added to x86_64,
    but later removed when x86_64 recieved an IRQ over-haul
    that made it unnecessary -- including per-CPU
    IRQ vectors that greatly increased the IRQ capacity
    on the machine.
    
    i386 has not received the analogous over-haul,
    and thus a previous attempt to delete IRQ compression
    from i386 was rejected on the theory that there may
    exist machines that actually need it.  The fact is
    that the author of IRQ compression patch was unable
    to confirm the actual existence of such a system.
    
    As a result, all i386 kernels with IOAPIC support
    pay the following:
    
    1. confusion
    
    IRQ compression re-names the traditional IOAPIC
    pin numbers (aka ACPI GSI's) into sequential IRQ #s:
    
    ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 16
    ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 21 (level, low) -> IRQ 17
    ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 22 (level, low) -> IRQ 18
    ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 23 (level, low) -> IRQ 19
    ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 20 (level, low) -> IRQ 16
    
    This makes /proc/interrupts look different
    depending on system configuration and device probe order.
    It is also different than the x86_64 kernel running
    on the exact same system.  As a result, programmers
    get confused when comparing systems.
    
    2. complexity
    
    The IRQ code in Linux is already overly complex,
    and IRQ compression makes it worse.  There have
    already been two bug workarounds related to IRQ
    compression -- the IRQ0 timer workaround and
    the VIA PCI IRQ workaround.
    
    3. size
    
    All i386 kernels with IOAPIC support contain an int[4096] --
    a 4 page array to contain the renamed IRQs.
    
    So while the irq compression code on i386 should really
    be deleted -- even before merging the x86_64 irq-overhaul,
    this patch simply disables it on all high volume systems
    to avoid problems #1 and #2 on most all i386 systems.
    
    A large system with pin numbers >=64 will still have compression
    to conserve limited IRQ numbers for sparse IOAPICS.  However,
    the vast majority of the planet, those with only pin numbers < 64
    will use an identity GSI -> IRQ mapping.
    
    Signed-off-by: Len Brown <len.brown@intel.com>

diff --git a/arch/x86/kernel/mpparse_32.c b/arch/x86/kernel/mpparse_32.c
index 7a05a7f..468d6ed 100644
--- a/arch/x86/kernel/mpparse_32.c
+++ b/arch/x86/kernel/mpparse_32.c
@@ -1041,13 +1041,14 @@ void __init mp_config_acpi_legacy_irqs (void)
 }
 
 #define MAX_GSI_NUM	4096
+#define IRQ_COMPRESSION_START	64
 
 int mp_register_gsi(u32 gsi, int triggering, int polarity)
 {
 	int ioapic = -1;
 	int ioapic_pin = 0;
 	int idx, bit = 0;
-	static int pci_irq = 16;
+	static int pci_irq = IRQ_COMPRESSION_START;
 	/*
 	 * Mapping between Global System Interrups, which
 	 * represent all possible interrupts, and IRQs
@@ -1086,12 +1087,16 @@ int mp_register_gsi(u32 gsi, int triggering, int polarity)
 	if ((1<<bit) & mp_ioapic_routing[ioapic].pin_programmed[idx]) {
 		Dprintk(KERN_DEBUG "Pin %d-%d already programmed\n",
 			mp_ioapic_routing[ioapic].apic_id, ioapic_pin);
-		return gsi_to_irq[gsi];
+		return (gsi < IRQ_COMPRESSION_START ? gsi : gsi_to_irq[gsi]);
 	}
 
 	mp_ioapic_routing[ioapic].pin_programmed[idx] |= (1<<bit);
 
-	if (triggering == ACPI_LEVEL_SENSITIVE) {
+	/*
+	 * For GSI >= 64, use IRQ compression
+	 */
+	if ((gsi >= IRQ_COMPRESSION_START)
+		&& (triggering == ACPI_LEVEL_SENSITIVE)) {
 		/*
 		 * For PCI devices assign IRQs in order, avoiding gaps
 		 * due to unused I/O APIC pins.

             reply	other threads:[~2007-11-28  6:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28  6:21 Len Brown [this message]
2007-11-28  7:09 ` [PATCH] i386 IOAPIC: de-fang IRQ compression Eric W. Biederman
2007-12-04 12:26 ` Ingo Molnar
2007-12-04 18:46   ` Eric W. Biederman
2007-12-04 20:55   ` Christian Kujau
2007-12-04 21:28     ` Ingo Molnar
2007-12-05  0:39   ` Andrew Morton
2007-12-05  9:48     ` Ingo Molnar
2007-12-07  2:41       ` Len Brown
2007-12-07 19:16         ` Eric W. Biederman
2007-12-07 20:26           ` Ingo Molnar
2007-12-07 20:31             ` Ingo Molnar
2007-12-07 21:09             ` Eric W. Biederman
2007-12-05 13:25 ` Natalie Protasevich
2007-12-05 23:25   ` Eric W. Biederman
2007-12-05 23:48     ` Natalie Protasevich
2007-12-06  2:20       ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200711280121.18376.lenb@kernel.org \
    --to=lenb@kernel.org \
    --cc=ak@suse.de \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=protasnb@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).