Skip to content

L
linux
Switch branch/tag
  1. 13 Aug, 2019 37 commits
  3. 08 Aug, 2019 3 commits
    • Suganath Prabu's avatar
      scsi: mpt3sas: Update driver version to 31.100.00.00 · 6e0b7ca2
      Suganath Prabu authored 
      Updated driver version from 29.100.00.00 to 31.100.00.00 which is
equivalent to Phase 12 OOB.
Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      6e0b7ca2
    • Suganath Prabu's avatar
      scsi: mpt3sas: Run SAS DEVICE STATUS CHANGE EVENT from ISR · 54d74e6b
      Suganath Prabu authored 
      In some cases, like while performing extensive expander reset or phy reset,
user may observe that drives are not visible in OS. Driver's
firmware-worker thread is blocked for more than 120 seconds resulting in a
call trace.

1. Received target add event for Device A and hence driver has registered
this device to SML by calling sas_rphy_add(). SML has half added this
device and returned the control to the driver by quitting from
sas_rphy_add() API, and started some background scanning on this device A.

2. While background scanning is going on device A, driver has received SAS
DEVICE STATUS CHANGE EVENT with RC code "Internal device reset" event and
hence driver has set tm_busy flag for this Device A from FW worker thread
context. When tm_busy flag is set then driver return scsi commands with
device busy status asking the kernel to retry the command after some time.
So background scanning for device A will be waiting for this tm_busy to be
cleared.

3. Meanwhile driver has received a target add event for Device B and hence
driver called sas_rphy_add() API to register this device with SML. But
since background scanning for Device A is still pending and SML is not
quitting from sas_rphy_add(), the driver’s firmware worker thread got
blocked.

4. Now driver has received SAS DEVICE STATUS CHANGE EVENT with RC code
"Internal device reset complete" event. But as driver’s firmware worker
thread got blocked in Step3, it can’t process this event and it was not
clearing the tm_busy flag and deadlock occurred (where SML was waiting for
tm_busy flag to be cleared and our FW worker thread is waiting for SML to
quit from sas_device_rphy_add() API).

Same deadlock will be observed even if device B is getting removed in
step3. So to limit these types of deadlocks driver will process the SAS
DEVICE STATUS CHANGE EVENT events from ISR context instead of processing
this event from worker thread context.  This improvement avoids above
deadlock.
Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      54d74e6b
    • Suganath Prabu's avatar
      scsi: mpt3sas: Reduce the performance drop · 1edc6770
      Suganath Prabu authored 
      This patch is to reduce the performance drop depth observed on SATA HDD
when ATA PT command is outstanding.

Driver returns IO commands with status "SAM_STAT_BUSY" whenever ATA PT
command is outstanding. With this, IO commands will be retried until this
outstanding ATA PT to complete and hence we will observe drop in
performance.

As the driver is completing the subsequent IOs commands with SAM_STAT_BUSY
status, these IOs has to go though the block layer.  Hence it adds latency
to the IOs and large performance drop is observed.

So to reduce this performance dropp, added improvement in driver to return
the subsequent IOs with SCSI_MLQUEUE_DEVICE_BUSY status instead of
completing the IOs with SAM_STAT_BUSY status when ATA PT command is
outstanding. Sending command back with SCSI_MLQUEUE_DEVICE_BUSY does not go
through complete block layer stack (as scsi_done won't be called) SML will
immediately retry the command and this method will avoid latency of block
layer stack and the performance impact will be reduced.

On Local setup, ran 512k sequential read IO operation on HGST SATA drive
with existing driver & with this improvement drivers and here is the
result,

1. With existing driver: IOs are running at bandwidth of ~230 rMB/s and
whenever any ATA PT command is outstanding (e.g issued from systemd-udevd
daemon) then this bandwidth drops to ~150 rMB/s.

2. With this improvement driver: IOs are running at bandwidth of ~230 rMB/s
and whenever any ATA PT command is outstanding then this bandwidth drops to
just ~190 rMB/s.
Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1edc6770
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7