On 25/11/2021 13:46, Kashyap Desai wrote:
John -
I will try something this week and let you know.
John - I tested patchset and looks good. Issue reported at below thread is
fixed.
https://lore.kernel.org/linux-block/e4e92abbe9d52bcba6b8cc6c91c442cc@xxxxxxxxxxxxxx/
Here is perf top data.
5.70% [megaraid_sas] [k] complete_cmd_fusion
3.80% [megaraid_sas] [k]
megasas_build_and_issue_cmd_fusion
2.75% [kernel] [k] syscall_return_via_sysret
2.68% [kernel] [k] entry_SYSCALL_64
2.22% [kernel] [k] io_submit_one
2.19% [megaraid_sas] [k] megasas_build_ldio_fusion
1.95% [kernel] [k] llist_add_batch
1.80% [kernel] [k] llist_reverse_order
1.79% [kernel] [k] scsi_complete
1.73% [kernel] [k] scsi_queue_rq
1.66% [kernel] [k] check_preemption_disabled
1.37% [megaraid_sas] [k] megasas_queue_command
1.16% [kernel] [k] native_irq_return_iret
1.11% [kernel] [k] aio_complete_rw
1.07% [kernel] [k] read_tsc
1.06% fio [.] __fio_gettime
1.05% [kernel] [k] flush_smp_call_function_queue
1.03% [kernel] [k] blk_complete_reqs
1.00% [kernel] [k] blk_mq_free_request
0.98% [kernel] [k] sbitmap_get
I will continue testing and let you know how it goes.
ok, good to know, thanks. But I would still like to know what is
triggering blk_mq_queue_tag_busy_iter() so often. Indeed, as mentioned
in this cover letter, this function was hardly optimised before for
shared sbitmap.
And any opinion whether we would want this as a fix? Information
requested above would help explain why we would need it as a fix.
Cheers,
John
