Since we already in hard IRQ context when running megasas_isr(), so use
spin_lock() is enough, which is faster than spin_lock_irqsave().
Signed-off-by: Xianting Tian <[email protected]>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
index 2b7e7b5f3..bd186254d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3977,15 +3977,14 @@ static irqreturn_t megasas_isr(int irq, void *devp)
{
struct megasas_irq_context *irq_context = devp;
struct megasas_instance *instance = irq_context->instance;
- unsigned long flags;
irqreturn_t rc;
if (atomic_read(&instance->fw_reset_no_pci_access))
return IRQ_HANDLED;
- spin_lock_irqsave(&instance->hba_lock, flags);
+ spin_lock(&instance->hba_lock);
rc = megasas_deplete_reply_queue(instance, DID_OK);
- spin_unlock_irqrestore(&instance->hba_lock, flags);
+ spin_unlock(&instance->hba_lock);
return rc;
}
--
2.17.1
On Wed, 21 Oct 2020, Xianting Tian wrote:
> Since we already in hard IRQ context when running megasas_isr(),
On m68k, hard irq context does not mean interrupts are disabled. Are there
no other architectures in that category?
> so use spin_lock() is enough, which is faster than spin_lock_irqsave().
>
Is that measurable?
> Signed-off-by: Xianting Tian <[email protected]>
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 2b7e7b5f3..bd186254d 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -3977,15 +3977,14 @@ static irqreturn_t megasas_isr(int irq, void *devp)
> {
> struct megasas_irq_context *irq_context = devp;
> struct megasas_instance *instance = irq_context->instance;
> - unsigned long flags;
> irqreturn_t rc;
>
> if (atomic_read(&instance->fw_reset_no_pci_access))
> return IRQ_HANDLED;
>
> - spin_lock_irqsave(&instance->hba_lock, flags);
> + spin_lock(&instance->hba_lock);
> rc = megasas_deplete_reply_queue(instance, DID_OK);
> - spin_unlock_irqrestore(&instance->hba_lock, flags);
> + spin_unlock(&instance->hba_lock);
>
> return rc;
> }
>
On Thu, 22 Oct 2020, Tianxianting wrote:
> Do you mean Megasas raid can be used in m68k arch?
m68k is one example of an architecture on which the unstated assumptions
in your patch would be invalid. Does this help to clarify what I wrote?
If Megasas raid did work on m68k, I'm sure it could potentially benefit
from the theoretical performance improvement from your patch.
So perhaps you would consider adding support for slower CPUs like m68k.
Thanks,
Do you mean Megasas raid can be used in m68k arch?
-----Original Message-----
From: Finn Thain [mailto:[email protected]]
Sent: Thursday, October 22, 2020 10:25 AM
To: tianxianting (RD) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH] scsi: megaraid_sas: use spin_lock() in hard IRQ
On Wed, 21 Oct 2020, Xianting Tian wrote:
> Since we already in hard IRQ context when running megasas_isr(),
On m68k, hard irq context does not mean interrupts are disabled. Are there no other architectures in that category?
> so use spin_lock() is enough, which is faster than spin_lock_irqsave().
>
Is that measurable?
> Signed-off-by: Xianting Tian <[email protected]>
> ---
> drivers/scsi/megaraid/megaraid_sas_base.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 2b7e7b5f3..bd186254d 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -3977,15 +3977,14 @@ static irqreturn_t megasas_isr(int irq, void
> *devp) {
> struct megasas_irq_context *irq_context = devp;
> struct megasas_instance *instance = irq_context->instance;
> - unsigned long flags;
> irqreturn_t rc;
>
> if (atomic_read(&instance->fw_reset_no_pci_access))
> return IRQ_HANDLED;
>
> - spin_lock_irqsave(&instance->hba_lock, flags);
> + spin_lock(&instance->hba_lock);
> rc = megasas_deplete_reply_queue(instance, DID_OK);
> - spin_unlock_irqrestore(&instance->hba_lock, flags);
> + spin_unlock(&instance->hba_lock);
>
> return rc;
> }
>
Yes, thanks
I see, If we add this patch, we need to get all cpu arch that support nested interrupts.
-----Original Message-----
From: Finn Thain [mailto:[email protected]]
Sent: Thursday, October 22, 2020 11:29 AM
To: tianxianting (RD) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: RE: [PATCH] scsi: megaraid_sas: use spin_lock() in hard IRQ
On Thu, 22 Oct 2020, Tianxianting wrote:
> Do you mean Megasas raid can be used in m68k arch?
m68k is one example of an architecture on which the unstated assumptions in your patch would be invalid. Does this help to clarify what I wrote?
If Megasas raid did work on m68k, I'm sure it could potentially benefit from the theoretical performance improvement from your patch.
So perhaps you would consider adding support for slower CPUs like m68k.
On Thu, 22 Oct 2020, Tianxianting wrote:
> I see, If we add this patch, we need to get all cpu arch that support
> nested interrupts.
>
I was just calling into question 1. the benefit (does it improve
performance?) and 2. the code style (is it less portable?).
It's really the style question that mostly interests me because I've had
to code around the nested interrupt situation before, and everytime it
comes up it makes me wonder about the necessity.
I was not trying to veto your patch. It is not my position to do that. If
Broadcom likes the patch, that's great.