linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: QiuLaibin <qiulaibin@huawei.com>
To: <ming.lei@redhat.com>, <axboe@kernel.dk>,
	<linux-kernel@vger.kernel.org>, <linux-block@vger.kernel.org>
Cc: <martin.petersen@oracle.com>, <hare@suse.de>,
	<asml.silence@gmail.com>, <bvanassche@acm.org>
Subject: Re: [PATCH -next] blk-mq: fix tag_get wait task can't be awakened
Date: Wed, 10 Nov 2021 15:33:35 +0800	[thread overview]
Message-ID: <3190660d-452e-690c-371f-e75744d37785@huawei.com> (raw)
In-Reply-To: <dddba25b-82d3-39c7-a58d-9d2b1adda8ae@huawei.com>


Hi Ming,

On 2021/09/26 20:48, Ming Lei wrote:
 > Hi Laibin,
 >
 > On Mon, Sep 13, 2021 at 04:12:48PM +0800, Laibin Qiu wrote:
 >> When multiple hctx share one tagset. The wake_batch is calculated
 >> during initialization by queue_depth. But when multiple hctx share one
 >> tagset. The queue depth assigned to each user may be smaller than
 >> wakeup_batch. This may cause the waiting queue to fail to wakup and
 >> leads to Hang.
 > In case of shared tags, there might be more than one hctx which 
allocates tag from single tags, and each hctx is limited to allocate at 
most:
 >
 > hctx_max_depth = max((bt->sb.depth + users - 1) / users, 4U);
 >
 > and
 >
 > users = atomic_read(&hctx->tags->active_queues)
 >
 > See hctx_may_queue().
 >
 > tag idle detection is lazy, and may be delayed for 30sec, so there 
could be just one real active hctx(queue) but all others are actually 
idle and still accounted as active because of the lazy idle detection. 
Then if wake_batch is > hctx_max_depth, driver tag allocation may wait 
forever on this real active hctx.
 >
 > Correct me if my understanding is wrong.

Your understanding is right. When we add lots of users for one shared 
tag, it will make wake_batch > hctx_max_dept. So driver tag allocation 
may wait forever on this real active hctx.

 >> Fix this by recalculating wake_batch when inc or dec active_queues.
 >>
 >> Fixes: 0d2602ca30e41 ("blk-mq: improve support for shared tags maps")
 >> Signed-off-by: Laibin Qiu <qiulaibin@huawei.com>
 >> ---
 >> block/blk-mq-tag.c | 44 +++++++++++++++++++++++++++++++++++++++--
 >> include/linux/sbitmap.h | 8 ++++++++
 >> lib/sbitmap.c | 3 ++-
 >> 3 files changed, 52 insertions(+), 3 deletions(-)
 >>
 >> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c index
 >> 86f87346232a..d02f5ac0004c 100644
 >> --- a/block/blk-mq-tag.c
 >> +++ b/block/blk-mq-tag.c
 >> @@ -16,6 +16,27 @@
 >> #include "blk-mq-sched.h"
 >> #include "blk-mq-tag.h"
 >> +static void bt_update_wake_batch(struct sbitmap_queue *bt, unsigned
 >> +int users) {
 >> + unsigned int depth;
 >> +
 >> + depth = max((bt->sb.depth + users - 1) / users, 4U);
 >> + sbitmap_queue_update_wake_batch(bt, depth);
 > Use the hctx's max queue depth could reduce wake_batch a lot, then 
performance may be degraded.
 >
 > Just wondering why not set sbq->wake_batch as hctx_max_depth if
 > sbq->wake_batch is < hctx_max_depth?
 >

__blk_mq_tag_busy() will add Users and __blk_mq_tag_idle() will decrease 
Users. Only changes in Users will affect each user's max depth. So we 
recalculate the matching wake_batch by 
sbitmap_queue_update_wake_batch(). sbitmap_queue_update_wake_batch() 
will calculate wake_batch by incoming depth. The value of 
sbq->wake_batch will only be changed when the calculated wake_batch changes.

static void sbitmap_queue_update_wake_batch(struct sbitmap_queue *sbq,
                                             unsigned int depth)
{
         unsigned int wake_batch = sbq_calc_wake_batch(sbq, depth);
^^^^^^^^^^^^^^^^^
         int i;
         if (sbq->wake_batch != wake_batch) {
             ^^^^^^^^^^^^^^^^^^
                 WRITE_ONCE(sbq->wake_batch, wake_batch);
                 /*
                  * Pairs with the memory barrier in sbitmap_queue_wake_up()
                  * to ensure that the batch size is updated before the wait
                  * counts.
                  */
                 smp_mb();
                 for (i = 0; i < SBQ_WAIT_QUEUES; i++)
                         atomic_set(&sbq->ws[i].wait_cnt, 1);
         }
}

 >
 > Thanks,
 > Ming

Thanks
Laibin

       reply	other threads:[~2021-11-10  7:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <dddba25b-82d3-39c7-a58d-9d2b1adda8ae@huawei.com>
2021-11-10  7:33 ` QiuLaibin [this message]
     [not found] <16d831ec8e624fb5acb7ad8f2dc0b7bf@huawei.com>
2021-09-16 14:13 ` [PATCH -next] blk-mq: fix tag_get wait task can't be awakened QiuLaibin
2021-09-13  8:12 Laibin Qiu
2021-09-26 12:47 ` Ming Lei

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=3190660d-452e-690c-371f-e75744d37785@huawei.com \
    --to=qiulaibin@huawei.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).