> > But your change seems effectively the same as in > https://lore.kernel.org/all/1638794990-137490-4-git-send-email- > john.garry@xxxxxxxxxx/, > which is now merged in Jens' 5.17 queue: > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux- > block.git/commit/?h=for- > 5.17/block&id=fea9f92f1748083cb82049ed503be30c3d3a9b69 John - Yes, above is the same changes I was looking for. I did very basic mistake. I applied your above commit while doing megaraid_sas testing. While I move to mpi3mr testing, I did not apply your patch set. We can drop request of this RFT since I tested above series and it serve the same purpose. Kashyap > > > While doing additional testing for [1], I noticed some performance > > issue. > > Along with the performance issue, I noticed CPU lockup as well. Lockup > > trace - > > > > _raw_spin_lock_irqsave+0x42/0x50 > > blk_mq_find_and_get_req+0x20/0xa0 > > bt_iter+0x2d/0x80 > > blk_mq_queue_tag_busy_iter+0x1aa/0x2f0 > > ? blk_mq_complete_request+0x30/0x30 > > ? blk_mq_complete_request+0x30/0x30 > > ? __schedule+0x360/0x850 > > blk_mq_timeout_work+0x5e/0x120 > > process_one_work+0x1a8/0x380 > > worker_thread+0x30/0x380 > > ? wq_calc_node_cpumask.isra.30+0x100/0x100 > > kthread+0x167/0x190 > > ? set_kthread_struct+0x40/0x40 > > ret_from_fork+0x22/0x30 > > > > It is a generic performance issue if driver use " shost->host_tagset = > > 1". > > In fact, I found that [1] is useful to fix performance issue and > > provided this additional patch. > > > > I changed my setup to have 64 scsi_devices (earlier I just kept 16 or > > 24 drives, so did not noticed this issue). Performance/cpu lockup > > issue is not due to [1]. > > More number of scsi device, hardware context per host and high queue > > depth will increase the chances of lockup and performance drop. > > > > Do you think, it is good to have changes in 5.16 + stable ? > > I don't know if this patch will create any side effect. Can you > > review and let me know your feedback. ? > > > > Can you test my merged change again for this scenario? > > I will also note that I mentioned previously that > blk_mq_queue_tag_busy_iter() was not optimum for shared sbitmap, i.e. > before shared tags, but no one said performance was bad for shared > sbitmap. > > Thanks, > John
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
