From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Anirban Chakraborty <anirban.chakraborty@qlogic.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"douglas.w.styner@intel.com" <douglas.w.styner@intel.com>
Subject: Re: [PATCH] qla2xxx: Resolved a performance issue in interrupt handler
Date: Tue, 9 Jun 2009 14:40:44 -0700 (PDT) [thread overview]
Message-ID: <alpine.OSX.1.00.0906091436120.4405@ac-mac.local> (raw)
In-Reply-To: <1244580029.12321.138.camel@mulgrave.site>
On Tue, 9 Jun 2009, James Bottomley wrote:
> On Tue, 2009-06-09 at 13:34 -0700, Anirban Chakraborty wrote:
> > On Jun 9, 2009, at 12:32 PM, James Bottomley wrote:
> >
> > > On Tue, 2009-06-09 at 11:42 -0700, Anirban Chakraborty wrote:
> > >> Reverted back a change from spin_lock to spin_lock_irq* that was
> > >> causing
> > >> the cycle times to go up.
> > >> The patch is based on scsi-misc-2.6.
> > >
> > > Some more explanation of this would be greatly appreciated. The cause
> > > looks to be that holding off interrupts in the isr could potentially
> > > reduce latency (caused by taking a different interrupt while holding
> > > the
> > > hardware lock) and increase the chance of coalescing (by holding off
> > > interrupts). However, if that's the case, possibly using an
> > > IRQF_DISABLED isr rather than going back to spin_lock_irqsave()
> > > would be
> > > a better fix?
> > The primary cause is, as you mentioned, the contention for the
> > hardware lock in the isr.
> > I'll check it with IRQF_DISABLED too. However, I was wondering if
> > there is any additional savings if we use IRQF_DISABLED vs. using the
> > spin_lock_irqsave. In the former case, probably we'd enter the isr
> > with interrupts disabled and in the latter case it would be done upon
> > entering the isr.
>
> It depends what the root cause is ... if it's really latency introduced
> by other interrupts, then IRQF_DISABLED might be the better course. If
> it's purely interrupt problems in the spin locked critical sections,
> then spin_lock_irq might be the better solution ... what would be useful
> is to have the test rig at intel which turned up the problem see what
> happens to the results for each case.
>
> James
I have attached the patch with IRQF_DISABLED. In my setup, I didn't find any
significant difference in performance numbers between IRQF_DISABLED and
spin_lock_irqsave. It would be interesting to see the numbers from Douglas's
rig.
Doug, could you please run it once more with this patch and let us know the
numbers vs. the one you already tested with spin_lock_irqsave earlier.
Thanks much,
Anirban
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index c8d0a17..d07bd97 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -1991,7 +1991,7 @@ skip_msix:
skip_msi:
ret = request_irq(ha->pdev->irq, ha->isp_ops->intr_handler,
- IRQF_SHARED, QLA2XXX_DRIVER_NAME, rsp);
+ IRQF_DISABLED, QLA2XXX_DRIVER_NAME, rsp);
if (ret) {
qla_printk(KERN_WARNING, ha,
"Failed to reserve interrupt %d already in use.\n",
next prev parent reply other threads:[~2009-06-09 21:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 18:42 [PATCH] qla2xxx: Resolved a performance issue in interrupt handler Anirban Chakraborty
2009-06-09 19:32 ` James Bottomley
2009-06-09 20:34 ` Anirban Chakraborty
2009-06-09 20:40 ` James Bottomley
2009-06-09 21:28 ` Giridhar Malavali
2009-06-09 21:41 ` Matthew Wilcox
2009-06-09 21:46 ` James Bottomley
2009-06-09 21:40 ` Anirban Chakraborty [this message]
2009-06-09 21:43 ` Matthew Wilcox
2009-06-09 21:46 ` Anirban Chakraborty
2009-06-09 21:47 ` Matthew Wilcox
2009-06-09 22:30 ` Anirban Chakraborty
[not found] ` <D7C42C27E6CB1E4D8CBDF2F81EA92A26035402EBA0@azsmsx501.amr.corp.intel.com>
[not found] ` <2796FDDF-31EA-44E2-8856-84A22F31A01F@qlogic.com>
2009-06-10 15:52 ` Styner, Douglas W
2009-06-10 16:09 ` Anirban Chakraborty
2009-06-10 16:17 ` James Bottomley
2009-06-10 16:18 ` Matthew Wilcox
2009-06-10 18:29 ` Anirban Chakraborty
2009-06-10 18:32 ` [PATCH] qla2xxx: Resolved a performance issue in interrupt Andrew Vasquez
2009-06-10 19:10 ` James Bottomley
2009-06-10 19:48 ` Matthew Wilcox
2009-06-10 20:55 ` Anirban Chakraborty
2009-06-12 22:48 ` Styner, Douglas W
2009-06-12 22:52 ` [PATCH] qla2xxx: Resolved a performance issue in interrupt - this time with data Styner, Douglas W
2009-06-12 23:32 ` Anirban Chakraborty
[not found] <B8134F80-B547-4E04-890A-6B646D2BA3E8@qlogic.com>
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=alpine.OSX.1.00.0906091436120.4405@ac-mac.local \
--to=anirban.chakraborty@qlogic.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=douglas.w.styner@intel.com \
--cc=linux-scsi@vger.kernel.org \
/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