From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Cc: linux-scsi@vger.kernel.org, douglas.w.styner@intel.com
Subject: Re: [PATCH] qla2xxx: Resolved a performance issue in interrupt handler
Date: Tue, 09 Jun 2009 19:32:24 +0000 [thread overview]
Message-ID: <1244575944.12321.58.camel@mulgrave.site> (raw)
In-Reply-To: <alpine.OSX.1.00.0906091107470.3891@ac-mac.local>
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?
> Reported-and-checked-by: Douglas W. Styner <douglas.w.styner@intel.com>
> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> ---
> drivers/scsi/qla2xxx/qla_isr.c | 30 ++++++++++++++++++------------
> 1 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index c8d0a17..bc92feb 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -37,6 +37,7 @@ qla2100_intr_handler(int irq, void *dev_id)
> uint16_t hccr;
> uint16_t mb[4];
> struct rsp_que *rsp;
> + unsigned long flags;
>
> rsp = (struct rsp_que *) dev_id;
> if (!rsp) {
> @@ -49,7 +50,7 @@ qla2100_intr_handler(int irq, void *dev_id)
> reg = &ha->iobase->isp;
> status = 0;
>
> - spin_lock(&ha->hardware_lock);
> + spin_lock_irqsave(&ha->hardware_lock, flags);
> vha = pci_get_drvdata(ha->pdev);
> for (iter = 50; iter--; ) {
> hccr = RD_REG_WORD(®->hccr);
> @@ -101,7 +102,7 @@ qla2100_intr_handler(int irq, void *dev_id)
> RD_REG_WORD(®->hccr);
> }
> }
> - spin_unlock(&ha->hardware_lock);
> + spin_unlock_irqrestore(&ha->hardware_lock, flags);
>
> if (test_bit(MBX_INTR_WAIT, &ha->mbx_cmd_flags) &&
> (status & MBX_INTERRUPT) && ha->flags.mbox_int) {
> @@ -133,6 +134,7 @@ qla2300_intr_handler(int irq, void *dev_id)
> uint16_t mb[4];
> struct rsp_que *rsp;
> struct qla_hw_data *ha;
> + unsigned long flags;
>
> rsp = (struct rsp_que *) dev_id;
> if (!rsp) {
> @@ -145,7 +147,7 @@ qla2300_intr_handler(int irq, void *dev_id)
> reg = &ha->iobase->isp;
> status = 0;
>
> - spin_lock(&ha->hardware_lock);
> + spin_lock_irqsave(&ha->hardware_lock, flags);
> vha = pci_get_drvdata(ha->pdev);
> for (iter = 50; iter--; ) {
> stat = RD_REG_DWORD(®->u.isp2300.host_status);
> @@ -216,7 +218,7 @@ qla2300_intr_handler(int irq, void *dev_id)
> WRT_REG_WORD(®->hccr, HCCR_CLR_RISC_INT);
> RD_REG_WORD_RELAXED(®->hccr);
> }
> - spin_unlock(&ha->hardware_lock);
> + spin_unlock_irqrestore(&ha->hardware_lock, flags);
>
> if (test_bit(MBX_INTR_WAIT, &ha->mbx_cmd_flags) &&
> (status & MBX_INTERRUPT) && ha->flags.mbox_int) {
> @@ -1626,6 +1628,7 @@ qla24xx_intr_handler(int irq, void *dev_id)
> uint32_t hccr;
> uint16_t mb[4];
> struct rsp_que *rsp;
> + unsigned long flags;
>
> rsp = (struct rsp_que *) dev_id;
> if (!rsp) {
> @@ -1638,7 +1641,7 @@ qla24xx_intr_handler(int irq, void *dev_id)
> reg = &ha->iobase->isp24;
> status = 0;
>
> - spin_lock(&ha->hardware_lock);
> + spin_lock_irqsave(&ha->hardware_lock, flags);
> vha = pci_get_drvdata(ha->pdev);
> for (iter = 50; iter--; ) {
> stat = RD_REG_DWORD(®->host_status);
> @@ -1688,7 +1691,7 @@ qla24xx_intr_handler(int irq, void *dev_id)
> WRT_REG_DWORD(®->hccr, HCCRX_CLR_RISC_INT);
> RD_REG_DWORD_RELAXED(®->hccr);
> }
> - spin_unlock(&ha->hardware_lock);
> + spin_unlock_irqrestore(&ha->hardware_lock, flags);
>
> if (test_bit(MBX_INTR_WAIT, &ha->mbx_cmd_flags) &&
> (status & MBX_INTERRUPT) && ha->flags.mbox_int) {
> @@ -1706,6 +1709,7 @@ qla24xx_msix_rsp_q(int irq, void *dev_id)
> struct rsp_que *rsp;
> struct device_reg_24xx __iomem *reg;
> struct scsi_qla_host *vha;
> + unsigned long flags;
>
> rsp = (struct rsp_que *) dev_id;
> if (!rsp) {
> @@ -1716,13 +1720,13 @@ qla24xx_msix_rsp_q(int irq, void *dev_id)
> ha = rsp->hw;
> reg = &ha->iobase->isp24;
>
> - spin_lock_irq(&ha->hardware_lock);
> + spin_lock_irqsave(&ha->hardware_lock, flags);
This doesn't make a lot of sense. I can see in the ordinary isr above,
you were using spin_lock not spin_lock_irq, so you were going into the
spin with other interrupts enabled. However, in the MSIX case, the net
effect of the code (since we enter with interrupts enabled) is nil plus
the small latency saving and restoring the flags.
I'm assuming Intel did the tests on a MSIX system, so I have a hard time
understanding how this could in any way fix their problem.
James
next prev parent reply other threads:[~2009-06-09 19:32 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 [this message]
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
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=1244575944.12321.58.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=anirban.chakraborty@qlogic.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