5:29 p.m.
> From: Hannes Reinecke <hare(a)suse.de>
> Date: Wed, 18 Nov 2020 08:08:41 +0100
> Subject: [PATCH] megaraid_sas: use scsi_device_busy() instead of
> direct access to atomic counter
>
> It's always a bad style to access structure internals, especially if
> there is an accessor for it. So convert to use scsi_device_busy()
> intead of accessing the atomic counter directly.
>
> Cc: Kashyap Desai <kashyap.desai(a)broadcom.com>
> Cc: Sumanesh Samanta <sumanesh.samanta(a)broadcom.com>
> Signed-off-by: Hannes Reinecke <hare(a)suse.de>
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index fd607287608e..272ff123bc6b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -362,7 +362,7 @@ megasas_get_msix_index(struct megasas_instance
*instance,
> /* TBD - if sml remove device_busy in future, driver
> * should track counter in internal structure.
> */
> - sdev_busy = atomic_read(&scmd->device->device_busy);
> + sdev_busy = scsi_device_busy(scmd->device);
megasas_get_msix_index() is called in .queuecommand() path,
scsi_device_busy() might take more cycles since it has to iterate over
each
sbitmap words, especially when the sbitmap depth is high.
I'd suggest Kashyap/Sumanesh to check if there is better way to deal
with it.
If
not, scsi_device_busy() should be fine.
Scsi_device_busy() add significant amount of overhead which will be
visible in terms of reduced IOPS and high CPU cycle. I tested it earlier
and noticed regression in performance.
I posted megaraid_sas driver patch which will use internal per sdev
outstanding similar to legacy sdev_busy counter.
Kashyap
Thanks,
Ming