You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
isert-scst has a dedicated workqueue where RDMA completion handler (isert_cq_comp_work_cb) runs. New commands arrive to isert_cq_comp_work_cb() that eventually checks (in scst_translate_lun()) if SCST is suspended:
If SCST is suspended, scst_init_cmd() sleeps 50ms in order to "keep initiator away from too many BUSY commands".
The problem is that this sleep sticks the workqueue thread, that is responsible also to complete "old" requests, that were received before scst_suspend_activity(). As a result suspend itself may take much time, because "old" commands do not get thread context to be finished.
For example in my environment with ~80 outstanding commands suspend takes ~3sec. If I comment out msleep(50) in scst_init_cmd(), it takes just ~100ms.
The text was updated successfully, but these errors were encountered:
isert-scst has a dedicated workqueue where RDMA completion handler (isert_cq_comp_work_cb) runs. New commands arrive to isert_cq_comp_work_cb() that eventually checks (in scst_translate_lun()) if SCST is suspended:
If SCST is suspended, scst_init_cmd() sleeps 50ms in order to "keep initiator away from too many BUSY commands".
The problem is that this sleep sticks the workqueue thread, that is responsible also to complete "old" requests, that were received before scst_suspend_activity(). As a result suspend itself may take much time, because "old" commands do not get thread context to be finished.
For example in my environment with ~80 outstanding commands suspend takes ~3sec. If I comment out msleep(50) in scst_init_cmd(), it takes just ~100ms.
The text was updated successfully, but these errors were encountered: