scsi: core: Replace sdev->device_busy with sbitmap
SCSI currently uses an atomic variable to track queue depth for each
attached device. The queue depth depends on many factors such as transport
type and device implementation. In addition, the SCSI device queue depth is
not a static entity but changes over time as a result of congestion
management.
While blk-mq currently tracks queue depth for each hctx, it can't easily be
changed to accommodate the SCSI per-device requirement.
The current approach of using an atomic variable doesn't scale well when
there are lots of CPU cores and the disk is very fast. IOPS can be
substantially impacted by the atomic in the hot path.
Replace the atomic variable sdev->device_busy with an sbitmap for tracking
the SCSI device queue depth.
It has been observed that IOPS is improved ~30% by this patchset in the
following test:
1) test machine(32 logical CPU cores)
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 2
NUMA node(s): 2
Model name: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz
scsi: mpt3sas: Fix error return value in _scsih_expander_add()
When an expander does not contain any 'phys', an appropriate error code -1
should be returned, as done elsewhere in this function. However, we
currently do not explicitly assign this error code to 'rc'. As a result, 0
was incorrectly returned.
Link: https://<email address hidden>
Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
Reported-by: Hulk Robot <email address hidden>
Signed-off-by: Zhen Lei <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit d6c2ce435ffe23ef7f395ae76ec747414589db46)
Signed-off-by: Michael Reed <email address hidden>
Fix the structurally dead code (UNREACHABLE) type of error reported by
Coverity.
Link: https://lore<email address hidden>
Reported-by: Colin Ian King <email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit cf750be8e68e8c2755f0ee29784463a2da91e922)
Signed-off-by: Michael Reed <email address hidden>
fa44e14...
by
"Gustavo A. R. Silva" <email address hidden>
scsi: mpt3sas: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding break statements instead of just letting
the code fall through to the next case.
scsi: mpt3sas: Handle firmware faults during second half of IOC init
If a firmware fault occurs while scanning the devices during IOC
initialization then the driver issues the hard reset operation to recover
the IOC. However, the driver is not issuing a Port enable request
message as part of hard reset operation during IOC initialization. Due to
this, the driver will not receive get any device discovery-related events
and hence devices will not be accessible.
Teach the driver to gracefully handle firmware faults while scanning for
target devices during IOC initialization. Make the driver issue a port
enable request message as part of hard reset operation. This permits
receiving device discovery-related events from the firmware after the hard
reset operation completes.
Link: https://lore<email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit a0815c45c89f544861eae55d85ccee6b1b1451e8)
Signed-off-by: Michael Reed <email address hidden>
scsi: mpt3sas: Handle firmware faults during first half of IOC init
During first half of IOC initialization (i.e. before going for device
scanning), if any firmware fault occurs then driver is aborting the IOC
initialization operation.
Modify the driver to issue a diag reset operation to recover IOC from fault
state and reinitialize the IOC.
Link: https://lore<email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit 19a622c39a9d497d3c06ffe9068ee4c7bbd2bdcc)
Signed-off-by: Michael Reed <email address hidden>
scsi: mpt3sas: Fix deadlock while cancelling the running firmware event
Do not cancel current running firmware event work if the event type is
different from MPT3SAS_REMOVE_UNRESPONDING_DEVICES. Otherwise a deadlock
can be observed while cancelling the current firmware event work if a hard
reset operation is called as part of processing the current event.
Link: https://lore<email address hidden>
Signed-off-by: Suganath Prabu S <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
(cherry picked from commit e2fac6c44ae06e58ac02181b048af31195883c31)
Signed-off-by: Michael Reed <email address hidden>
