All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Cleverdon <jamesclv@us.ibm.com>
To: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: Andi Kleen <ak@suse.de>, "Brown, Len" <len.brown@intel.com>,
	Russ Weight <rweight@us.ibm.com>,
	linux-kernel@vger.kernel.org, zwane@arm.linux.org.uk
Subject: Re: [RFC][2.6.12.3] IRQ compression/sharing patch
Date: Wed, 10 Aug 2005 20:14:13 -0700	[thread overview]
Message-ID: <200508102014.14138.jamesclv@us.ibm.com> (raw)
In-Reply-To: <19D0D50E9B1D0A40A9F0323DBFA04ACCE04CB0@USRV-EXCH4.na.uis.unisys.com>

On Wednesday 10 August 2005 05:21 pm, Protasevich, Natalie wrote:
> > > int gsi_irq_sharing(int gsi)
> > > {
> > >         int i, irq, vector;
> > >
> > >         BUG_ON(gsi >= NR_IRQ_VECTORS);
> > >
> > >         if (platform_legacy_irq(gsi)) {
> > >                 gsi_2_irq[gsi] = gsi;
> > >                 return gsi;
> > >         }
> > >
> > >         if (gsi_2_irq[gsi] != 0xFF)
> > >                 return (int)gsi_2_irq[gsi];
> > >
> > >         vector = assign_irq_vector(gsi); // this part
> > > here==========
> >
> > I thought I had this case covered earlier, given that in both i386
> > and x86_64:
> >
> > #define platform_legacy_irq(irq)      ((irq) < 16)
>
> Yes, you are absolutely correct, I don't need the (gsi<16) part, this
> takes care of PCI IRQs that happened to be <16.
>
> > In the deleted vector sharing code, I also check
> > platform_legacy_irq, to avoid inadvertently sharing vectors
> > already assigned to legacy IRQs.
> >
> > Am I missing your point here?
> >
> > >         if (gsi < 16) {
> > >                 irq = gsi;
> > >                 gsi_2_irq[gsi] = irq;
> > >         } else {
> > >                 irq = next_irq++;
> > >                 gsi_2_irq[gsi] = irq;
> > >         }
> > > //====================
> >
> > I can't explain the gaps in the numbers with the original
> > version.  I'll give your variant a try.
>
> The only problem is here:
>
> +	if (i < NR_IRQS) {
> +		gsi_2_irq[gsi] = i;
> +		printk(KERN_INFO "GSI %d sharing vector 0x%02X and IRQ
> %d\n",
> +				gsi, vector, i);
> +		return i;
> +	}
> +
> +	i = next_irq++;
>
> That means for any IRQ < NR_IRQS you allow it to be identity mapped,
> with all the gaps, and only for ones exceeding 224 you'll assign
> consecutive next_irqs++, whereas you can do it for all PCI IRQs above
> 15. So, the alternative clause should probably come down to just:
>                  irq = next_irq++;
>                  gsi_2_irq[gsi] = irq; - which means just removing
> the one above...
> (although we better test that :)...I will definitely test vector
> sharing when manage to get on max configuration partition here.
>
> Regards,
> --Natalie

Blast.  You're right, because i is the results of scanning irq_vector 
(AKA IO_APIC_VECTOR()) for a previous use of the vector.  If i < 
NR_IRQS then it has found a previous use and would substitute the other 
IRQ number rather than allocate a new one.

Of course, one side effect of calling assign_irq_vector(gsi) is that the 
vector number is stored at position gsi in irq_vector.  So, for IRQs 0 
to NR_IRQS - 1, it will always find itself.

OK, how about not fighting that side effect and only reassigning IRQs
that are >= NR_IRQS?  Maybe something like this:

@@ -579,4 +589,57 @@ static inline int irq_trigger(int idx)
 	return MPBIOS_trigger(idx);
 }
 
+/*
+ * gsi_irq_sharing -- Name overload!  "irq" can be either a legacy IRQ
+ * in the range 0-15, a linux IRQ in the range 0-223, or a GSI number
+ * from ACPI, which can easily reach 800.
+ *
+ * Compact the sparse GSI space into a available IRQs and reuse
+ * vectors if possible.
+ */
+int gsi_irq_sharing(int gsi)
+{
+	int i, tries, vector;
+
+	BUG_ON(gsi >= NR_IRQ_VECTORS);
+
+	/*
+	 * Don't share legacy IRQs.  Their trigger modes are usually edge
+	 * and PCI is level.  Mixed modes are trouble.  Only big boxes are
+	 * likely to overflow IRQs or to share vectors.
+	 */
+	if (likely(gsi < NR_IRQS && !sharing_vectors) || platform_legacy_irq(gsi)) {
+		gsi_2_irq[gsi] = gsi;
+		return gsi;
+	}
+
+	if (gsi_2_irq[gsi] != 0xFF)
+		return gsi_2_irq[gsi];
+	/*
+	 * Ran out of vectors or IRQ >= NR_IRQS.  Sharing vectors
+	 * means sharing IRQs, so scan irq_vectors for previous use
+	 * of vector and return that IRQ.
+	 */
+	tries = NR_IRQS;
+  try_again:
+	vector = assign_irq_vector(gsi);
+
+	/* Find the first IRQ using vector. */
+	for (i = 0; i < NR_IRQS; i++)
+		if (IO_APIC_VECTOR(i) == vector)
+			break;
+
+	if (i >= NR_IRQS || platform_legacy_irq(i)) {
+		if (--tries >= 0) {
+			IO_APIC_VECTOR(gsi) = 0;
+			goto try_again;
+		}
+		panic("gsi_irq_sharing: didn't find an IRQ using vector 0x%02X for GSI %d", vector, gsi);
+	}
+	printk("GSI %d assigned vector 0x%02X and IRQ %d\n", gsi, vector, i);
+	gsi_2_irq[gsi] = i;
+	return i;
+}
+
 static int pin_2_irq(int idx, int apic, int pin)
 {
 	int irq, i;


-- 
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm

  reply	other threads:[~2005-08-11  3:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11  0:21 [RFC][2.6.12.3] IRQ compression/sharing patch Protasevich, Natalie
2005-08-11  3:14 ` James Cleverdon [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-08-15  4:35 Protasevich, Natalie
2005-08-15 17:11 ` James Cleverdon
2005-08-11 22:02 Protasevich, Natalie
2005-08-11 22:34 ` Zwane Mwaikambo
2005-08-11 21:55 Protasevich, Natalie
2005-08-12  1:07 ` James Cleverdon
2005-08-12  2:59 ` James Cleverdon
2005-08-11 13:15 Protasevich, Natalie
2005-08-11 17:24 ` James Cleverdon
2005-08-10 21:03 Protasevich, Natalie
2005-08-10 23:55 ` James Cleverdon
2005-08-11 17:52 ` Zwane Mwaikambo
2005-07-26  7:12 [RFC][2.6.13-rc3-mm1] " James Cleverdon
2005-07-26 16:03 ` Andi Kleen
2005-08-04  7:05   ` [RFC][2.6.12.3] " James Cleverdon
2005-08-04  9:22     ` Andi Kleen
2005-08-15  2:57       ` James Cleverdon
2005-08-15  5:55         ` Zwane Mwaikambo
2005-08-15 17:44         ` Andi Kleen
2005-08-16  3:24           ` James Cleverdon
2005-08-16  6:58             ` Andi Kleen

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=200508102014.14138.jamesclv@us.ibm.com \
    --to=jamesclv@us.ibm.com \
    --cc=Natalie.Protasevich@UNISYS.com \
    --cc=ak@suse.de \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rweight@us.ibm.com \
    --cc=zwane@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.