| Message ID | 20210111164717.21937-1-jack@suse.cz (mailing list archive) |
|---|---|
| Headers | show |
| Series | blk-mq: Improve performance of non-mq IO schedulers with multiple HW queues | expand |
On Mon 11-01-21 17:47:15, Jan Kara wrote: > Hello! > > This patch series aims to fix a regression we've noticed on our test grid when > support for multiple HW queues in megaraid_sas driver was added during the 5.10 > cycle (103fbf8e4020 scsi: megaraid_sas: Added support for shared host tagset > for cpuhotplug). The commit was reverted in the end for other reasons but I > believe the fundamental problem still exists for any other similar setup. The > problem manifests when the storage card supports multiple hardware queues > however storage behind it is slow (single rotating disk in our case) and so > using IO scheduler such as BFQ is desirable. See the second patch for details. > > Changes since v2 > * Modified code to avoid useless sbitmap_any_set() calls on submit path > > Changes since v1 > * Fixed queue running code to don't leave pending requests that bypass IO > scheduler. Jens, can you please pickup these patches? Thanks! Honza
On 1/11/21 9:47 AM, Jan Kara wrote: > Hello! > > This patch series aims to fix a regression we've noticed on our test grid when > support for multiple HW queues in megaraid_sas driver was added during the 5.10 > cycle (103fbf8e4020 scsi: megaraid_sas: Added support for shared host tagset > for cpuhotplug). The commit was reverted in the end for other reasons but I > believe the fundamental problem still exists for any other similar setup. The > problem manifests when the storage card supports multiple hardware queues > however storage behind it is slow (single rotating disk in our case) and so > using IO scheduler such as BFQ is desirable. See the second patch for details. Applied, thanks.
On 25/01/2021 01:20, Jens Axboe wrote: > On 1/11/21 9:47 AM, Jan Kara wrote: >> Hello! >> >> This patch series aims to fix a regression we've noticed on our test grid when >> support for multiple HW queues in megaraid_sas driver was added during the 5.10 >> cycle (103fbf8e4020 scsi: megaraid_sas: Added support for shared host tagset >> for cpuhotplug). The commit was reverted in the end for other reasons but I >> believe the fundamental problem still exists for any other similar setup. That commit made it into 5.11-rc, and other SCSI HBA expose HW queues in 5.10 and earlier. But then this series is targeted at 5.12. Question: can we consider backport this series just due to performance issue regression? I'd say no, but maybe someone strongly disagrees with me ... Thanks, John > The >> problem manifests when the storage card supports multiple hardware queues >> however storage behind it is slow (single rotating disk in our case) and so >> using IO scheduler such as BFQ is desirable. See the second patch for details.
On Wed 03-02-21 16:18:59, John Garry wrote: > On 25/01/2021 01:20, Jens Axboe wrote: > > On 1/11/21 9:47 AM, Jan Kara wrote: > > > Hello! > > > > > > This patch series aims to fix a regression we've noticed on our test grid when > > > support for multiple HW queues in megaraid_sas driver was added during the 5.10 > > > cycle (103fbf8e4020 scsi: megaraid_sas: Added support for shared host tagset > > > for cpuhotplug). The commit was reverted in the end for other reasons but I > > > believe the fundamental problem still exists for any other similar setup. > > That commit made it into 5.11-rc, and other SCSI HBA expose HW queues in > 5.10 and earlier. But then this series is targeted at 5.12. > > Question: can we consider backport this series just due to performance issue > regression? I'd say no, but maybe someone strongly disagrees with me ... I also don't consider my series a stable tree material. The setup of multiple HW queues with BFQ IO scheduler isn't really very common... Honza > > Thanks, > John > > > The > > > problem manifests when the storage card supports multiple hardware queues > > > however storage behind it is slow (single rotating disk in our case) and so > > > using IO scheduler such as BFQ is desirable. See the second patch for details. >