> > From: Hannes Reinecke <hare@xxxxxxx> > > 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@xxxxxxxxxxxx> > > Cc: Sumanesh Samanta <sumanesh.samanta@xxxxxxxxxxxx> > > Signed-off-by: Hannes Reinecke <hare@xxxxxxx> > > --- > > 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
