From: Ming Lei <ming.lei@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Yu Kuai <yukuai1@huaweicloud.com>, Ed Tsai <ed.tsai@mediatek.com>,
ming.lei@redhat.com
Subject: Re: [PATCH] block: Improve shared tag set performance
Date: Mon, 23 Oct 2023 11:44:08 +0800 [thread overview]
Message-ID: <ZTXsCGhGMk5w6qyi@fedora> (raw)
In-Reply-To: <c768b829-8c86-4574-a1ec-fcc0bf60e270@acm.org>
On Sat, Oct 21, 2023 at 09:13:38AM -0700, Bart Van Assche wrote:
> On 10/20/23 18:31, Ming Lei wrote:
> > If two LUNs are attached to same host, one is slow, and another is fast,
> > and the slow LUN can slow down the fast LUN easily without this fairness
> > algorithm.
> >
> > Your motivation is that "One of these logical units (WLUN) is used
> > to submit control commands, e.g. START STOP UNIT. If any request is
> > submitted to the WLUN, the queue depth is reduced from 31 to 15 or
> > lower for data LUNs." I guess one simple fix is to not account queues
> > of this non-IO LUN as active queues?
>
> Hi Ming,
>
> For fast storage devices (e.g. UFS) any time spent in an algorithm for
> fair sharing will reduce IOPS. If there are big differences in the
> request processing latency between different request queues then fair
> sharing is beneficial. Whether or not the fair sharing algorithm is
> improved, how about making it easy to disable fair sharing, e.g. with
> something like the untested patch below? I think that will work better
> than ignoring fair sharing per LUN. UFS devices support multiple logical
> units and with the current fair sharing approach it takes long until
> tags are taken away from an inactive LUN (request queue timeout).
>
> Thanks,
>
> Bart.
>
>
> diff --git a/block/blk-mq.h b/block/blk-mq.h
> index f75a9ecfebde..b06b161d06de 100644
> --- a/block/blk-mq.h
> +++ b/block/blk-mq.h
> @@ -416,7 +416,8 @@ static inline bool hctx_may_queue(struct blk_mq_hw_ctx
> *hctx,
> {
> unsigned int depth, users;
>
> - if (!hctx || !(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED))
> + if (!hctx || !(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED) ||
> + hctx->queue->disable_fair_sharing)
Maybe you can propagate this flag into hctx->flags, then
hctx->queue->disable_fair_sharing can be avoided in fast path.
> return true;
>
> /*
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index eef450f25982..63b04cf65887 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -523,6 +523,7 @@ struct request_queue {
> struct mutex debugfs_mutex;
>
> bool mq_sysfs_init_done;
> + bool disable_fair_sharing;
You also need to bypass blk_mq_tag_busy() & blk_mq_tag_idle()
in case of disable_fair_sharing which should only be set for
non-IO queues, such as UFS WLUN, and maybe nvme connection queues.
Thanks,
Ming
next prev parent reply other threads:[~2023-10-23 3:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 18:00 [PATCH] block: Improve shared tag set performance Bart Van Assche
2023-10-20 4:41 ` Christoph Hellwig
2023-10-20 16:17 ` Bart Van Assche
2023-10-20 16:25 ` Keith Busch
2023-10-20 16:45 ` Bart Van Assche
2023-10-20 17:09 ` Keith Busch
2023-10-20 17:54 ` Bart Van Assche
2023-10-21 1:31 ` Ming Lei
2023-10-21 16:13 ` Bart Van Assche
2023-10-23 3:44 ` Ming Lei [this message]
2023-10-20 19:11 ` Bart Van Assche
2023-10-21 7:32 ` Yu Kuai
2023-10-21 16:21 ` Bart Van Assche
2023-10-23 1:11 ` Yu Kuai
-- strict thread matches above, loose matches on Subject: below --
2023-01-02 17:39 Bart Van Assche
2023-01-03 0:47 ` kernel test robot
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=ZTXsCGhGMk5w6qyi@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=damien.lemoal@opensource.wdc.com \
--cc=ed.tsai@mediatek.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=yukuai1@huaweicloud.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.