From: Ming Lei <ming.lei@redhat.com>
To: Keith Busch <kbusch@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Jens Axboe <axboe@kernel.dk>,
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,
ming.lei@redhat.com
Subject: Re: [PATCH] scsi: ufs: mark HPB support as BROKEN
Date: Thu, 28 Oct 2021 08:42:20 +0800 [thread overview]
Message-ID: <YXnx7EIFMTH8czLa@T590> (raw)
In-Reply-To: <20211027161632.GB2338303@dhcp-10-100-145-180.wdc.com>
On Wed, Oct 27, 2021 at 09:16:32AM -0700, 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.
Yeah, that is why I thought the tag could be reused for the spawned(cloned)
request, but it needs ufshpb developer to confirm, or at least
ufshcd_queuecommand() can handle this situation. If that is true, it isn't
necessary to use reserve tags, since the current blk-mq implementation
requires to reserve real hardware tags space, which has to take normal
tags.
thanks,
Ming
next prev parent reply other threads:[~2021-10-28 0:42 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
2021-10-28 0:42 ` Ming Lei [this message]
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=YXnx7EIFMTH8czLa@T590 \
--to=ming.lei@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=axboe@kernel.dk \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.