public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Keith Busch <kbusch@kernel.org>, Ming Lei <ming.lei@redhat.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Christoph Hellwig <hch@lst.de>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	alim.akhtar@samsung.com, avri.altman@wdc.com,
	linux-scsi@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH] scsi: ufs: mark HPB support as BROKEN
Date: Wed, 27 Oct 2021 10:19:40 -0600	[thread overview]
Message-ID: <65ca1470-e3fd-f6e2-7da8-ce6c2259314b@kernel.dk> (raw)
In-Reply-To: <20211027161632.GB2338303@dhcp-10-100-145-180.wdc.com>

On 10/27/21 10:16 AM, Keith Busch wrote:
> On Wed, Oct 27, 2021 at 11:58:23PM +0800, Ming Lei wrote:
>> On Wed, Oct 27, 2021 at 11:44:04AM -0400, Martin K. Petersen wrote:
>>>
>>> Ming,
>>>
>>>> request with scsi_cmnd may be allocated by the ufshpb driver, even it
>>>> should be fine to call ufshcd_queuecommand() directly for this driver
>>>> private IO, if the tag can be reused. One example is scsi_ioctl_reset().
>>>
>>> scsi_ioctl_reset() allocates a new request, though, so that doesn't
>>> solve the forward progress guarantee. Whereas eh puts the saved request
>>> on the stack.
>>
>> What I meant is to use one totally ufshpb private command allocated from
>> private slab to replace the spawned request, which is sent to ufshcd_queuecommand()
>> directly, so forward progress is guaranteed if the blk-mq request's tag can be
>> reused for issuing this private command. This approach takes a bit effort,
>> but avoids tags reservation.
>>
>> Yeah, it is cleaner to use reserved tag for the spawned request, but we
>> need to know:
>>
>> 1) how many queue depth for the hba? If it is small, even 1 reservation
>> can affect performance.
>>
>> 2) how many inflight write buffer commands are to be supported? Or how many
>> is enough for obtaining expected performance? If the number is big, reserved
>> tags can't work.
> 
> The original and clone are not dispatched to hardware concurrently, so
> I don't think the reserved_tags need to subtract from the generic
> ones. The original request already accounts for the hardware resource,
> so the clone doesn't need to consume another one.

Maybe I didn't phrase it clearly enough, because that's not what I
meant. My point is that just one reserved tag is fine for the
correctness guarantee, you'd just only have one of these special
requests inflight at the time then and that may be a performance
concern. More reserved tags would allow more inflight at the same time.
This is totally independent of the normal tags available.

-- 
Jens Axboe


  reply	other threads:[~2021-10-27 16:19 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26  7:12 [PATCH] scsi: ufs: mark HPB support as BROKEN Christoph Hellwig
2021-10-26  7:18 ` Hannes Reinecke
2021-10-26  7:24 ` Damien Le Moal
2021-10-26 13:04   ` James Bottomley
2021-10-26 16:36 ` Bart Van Assche
2021-10-26 17:19   ` James Bottomley
2021-10-26 17:25     ` Jens Axboe
2021-10-26 18:05       ` Bart Van Assche
2021-10-26 18:10         ` Jens Axboe
2021-10-26 18:18           ` James Bottomley
2021-10-26 18:27             ` Martin K. Petersen
2021-10-26 20:10               ` Bart Van Assche
2021-10-26 22:22                 ` Daejun Park
2021-10-27  5:27                 ` Christoph Hellwig
2021-10-27 12:20                   ` James Bottomley
2021-10-28 20:21                     ` Bart Van Assche
2021-10-28 20:33                       ` James Bottomley
2021-10-28 20:53                         ` Bart Van Assche
2021-10-28 21:14                           ` Daejun Park
2021-10-27 13:16                   ` Bart Van Assche
2021-10-27 14:12                     ` Keith Busch
2021-10-27 14:38                       ` Jens Axboe
2021-10-27 14:43                         ` James Bottomley
2021-10-27 15:03                       ` Ming Lei
2021-10-27 15:06                         ` Jens Axboe
2021-10-27 15:16                           ` Ming Lei
2021-10-27 15:44                             ` Martin K. Petersen
2021-10-27 15:58                               ` Ming Lei
2021-10-27 16:16                                 ` Keith Busch
2021-10-27 16:19                                   ` Jens Axboe [this message]
2021-10-28  0:42                                   ` Ming Lei
2021-10-28  1:10                                     ` Daejun Park
2021-10-28  2:07                                       ` Ming Lei
2021-10-27 16:59                                 ` Martin K. Petersen
2021-10-27 15:35                           ` Martin K. Petersen
2021-10-27 15:40                             ` Jens Axboe
2021-10-27 16:16                               ` Martin K. Petersen
2021-10-27 17:01                                 ` Bart Van Assche
2021-10-28  1:32                                   ` Ming Lei
2021-10-29 10:53 ` Christoph Hellwig
2021-10-29 11:39   ` James Bottomley
2021-10-29 13:35     ` Avri Altman
2021-10-29 13:44       ` James Bottomley

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=65ca1470-e3fd-f6e2-7da8-ce6c2259314b@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=jaegeuk@kernel.org \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.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