[lkml]   [2019]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v1 1/2] scsi: ufs: unify scsi_block_requests usage
Hi Bart,

> Hi Stanley,
> From the SCSI core:
> void scsi_block_requests(struct Scsi_Host *shost)
> {
> shost->host_self_blocked = 1;
> }
> In other words, neither scsi_block_requests() nor
> ufshcd_scsi_block_requests() wait for ongoing ufshcd_queuecommand()
> calls to finish. Is it required to wait for these calls to finish before
> exceptions are handled? If not, can the scsi_block_requests() and
> scsi_unblock_requests() calls be left out? If it is required to wait for
> ongoing ufshcd_queuecommand() calls to finish then I think the
> scsi_block_requests() and scsi_unblock_requests() will have to be
> changed into something else.

ASFAIK, ufshcd_exception_event_handler() is not required to wait for
ongoing ufshcd_queuecommand() calls to finish.

The scsi_block_requests() call here is trying to increase successful
rate of requests sent by ufshcd_exception_event_handler() because
timeout may happen if device is too busy to handle those requests.
Blocking any future incoming requests can help.

As time goes by, actually current UFS driver allows more waiting time by
below changes for ufshcd_exception_event_handler(), and thus the
successful rate shall be raised much nowadays.

- Enlarge QUERY_REQ_TIMEOUT time from 100 ms to 1.5 seconds
- Allow retry if query requests are timed out

Therefore, the scsi_block_requests() call is actually a "helper" to help
ufshcd_exception_event_handler() successful. I think it could be better
kept to make UFS device recover its performance as soon as possible.

> Thanks,
> Bart.


 \ /
  Last update: 2019-12-25 05:08    [W:0.296 / U:27.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site