Re: [PATCH] UFS: Make TM command timeout configurable from host side

[Bart Van Assche <bvanassche@acm.org>]

On 11/13/25 2:08 AM, Peter Wang (王信友) wrote:
> In the worst-case scenario (when the device is stuck), it
> may takes 1.1 seconds to abort a single task. When the queue is
> full (64), there will be noticeable lag. Aborting all
> tasks can take over a minute, which is unacceptable regardless
> of whether TM_CMD_TIMEOUT is increased or not. Under normal
> conditions, it’s very unlikely to exceed 100ms. So I think
> directly modifying TM_CMD_TIMEOUT is also acceptable,
> but I suggest keeping it within 500ms.
Hi Peter,

Aborting different commands should happen concurrently rather than
sequentially. See also the queue_delayed_work() call in the SCSI core
scsi_abort_command() function:

queue_delayed_work(shost->tmf_work_q, &scmd->abort_work, HZ / 100);

Unfortunately the max_active argument is set to 1 in the call that 
creates tmf_work_q:

shost->tmf_work_q = alloc_workqueue("scsi_tmf_%d",
				WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_SYSFS,
				   1, shost->host_no);

Hannes, do you agree with increasing the max_active argument from 1 to
INT_MAX? I think the above code was introduced 12 years ago by commit
e494f6a72839 ("[SCSI] improved eh timeout handler").

Thanks,

Bart.