linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanley Chu <stanley.chu@mediatek.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: <linux-scsi@vger.kernel.org>, <martin.petersen@oracle.com>,
	<avri.altman@wdc.com>, <alim.akhtar@samsung.com>,
	<pedrom.sousa@synopsys.com>, <jejb@linux.ibm.com>,
	<matthias.bgg@gmail.com>, <beanhuo@micron.com>,
	<cang@codeaurora.org>, <linux-mediatek@lists.infradead.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <kuohong.wang@mediatek.com>,
	<peter.wang@mediatek.com>, <chun-hung.wu@mediatek.com>,
	<andy.teng@mediatek.com>
Subject: Re: [PATCH v1 1/2] scsi: ufs: unify scsi_block_requests usage
Date: Wed, 25 Dec 2019 12:07:43 +0800	[thread overview]
Message-ID: <1577246863.13056.48.camel@mtkswgap22> (raw)
In-Reply-To: <e9a8fbc0-5f08-75f5-b23b-2bbaa28a6222@acm.org>

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.

Thanks,
Stanley


  reply	other threads:[~2019-12-25  4:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-24 13:01 [PATCH v1 0/2] scsi: ufs: use existed well-defined functions Stanley Chu
2019-12-24 13:01 ` [PATCH v1 1/2] scsi: ufs: unify scsi_block_requests usage Stanley Chu
2019-12-24 15:46   ` Bart Van Assche
2019-12-25  4:07     ` Stanley Chu [this message]
2019-12-25  8:21   ` Can Guo
2019-12-26 17:38   ` Bart Van Assche
2019-12-24 13:01 ` [PATCH v1 2/2] scsi: ufs: use ufshcd_vops_dbg_register_dump for vendor specific dumps Stanley Chu
2019-12-24 15:47   ` Bart Van Assche
2019-12-25  8:18   ` Can Guo
2019-12-27  1:33 ` [PATCH v1 0/2] scsi: ufs: use existed well-defined functions Alim Akhtar
2020-01-03  2:58 ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1577246863.13056.48.camel@mtkswgap22 \
    --to=stanley.chu@mediatek.com \
    --cc=alim.akhtar@samsung.com \
    --cc=andy.teng@mediatek.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=chun-hung.wu@mediatek.com \
    --cc=jejb@linux.ibm.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=pedrom.sousa@synopsys.com \
    --cc=peter.wang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).