From: Jens Axboe <axboe@kernel.dk>
To: Guenter Roeck <linux@roeck-us.net>, Laibin Qiu <qiulaibin@huawei.com>
Cc: ming.lei@redhat.com, john.garry@huawei.com,
martin.petersen@oracle.com, hare@suse.de,
akpm@linux-foundation.org, bvanassche@acm.org,
andriy.shevchenko@linux.intel.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next V5] blk-mq: fix tag_get wait task can't be awakened
Date: Thu, 27 Jan 2022 10:28:22 -0700 [thread overview]
Message-ID: <bb1c7c15-ef4e-8c2f-4c01-758bf186e010@kernel.dk> (raw)
In-Reply-To: <20220127013238.GA1478141@roeck-us.net>
On 1/26/22 6:32 PM, Guenter Roeck wrote:
> Hi,
>
> On Thu, Jan 13, 2022 at 10:55:36AM +0800, Laibin Qiu wrote:
>> In case of shared tags, there might be more than one hctx which
>> allocates from the same tags, and each hctx is limited to allocate at
>> most:
>> hctx_max_depth = max((bt->sb.depth + users - 1) / users, 4U);
>>
>> 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.
>>
>> Fix this by recalculating wake_batch when inc or dec active_queues.
>>
>> Fixes: 0d2602ca30e41 ("blk-mq: improve support for shared tags maps")
>> Suggested-by: Ming Lei <ming.lei@redhat.com>
>> Suggested-by: John Garry <john.garry@huawei.com>
>> Signed-off-by: Laibin Qiu <qiulaibin@huawei.com>
>
> I understand this problem has been reported already, but still:
>
> This patch causes a hang in several of my qemu emulations when
> trying to boot from usb. Reverting it fixes the problem. Bisect log
> is attached.
>
> Boot logs are available at
> https://kerneltests.org/builders/qemu-arm-aspeed-master/builds/230/steps/qemubuildcommand/logs/stdio
> but don't really show much: the affected tests simply hang until they
> are aborted.
This one got reported a few days ago, can you check if applying:
https://git.kernel.dk/cgit/linux-block/commit/?h=block-5.17&id=10825410b956dc1ed8c5fbc8bbedaffdadde7f20
fixes it for you?
--
Jens Axboe
next prev parent reply other threads:[~2022-01-27 17:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 2:55 [PATCH -next V5] blk-mq: fix tag_get wait task can't be awakened Laibin Qiu
2022-01-13 10:51 ` Andy Shevchenko
2022-01-13 19:52 ` Jens Axboe
2022-01-27 1:32 ` Guenter Roeck
2022-01-27 17:28 ` Jens Axboe [this message]
2022-01-27 18:04 ` Guenter Roeck
2022-01-27 18:06 ` Jens Axboe
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=bb1c7c15-ef4e-8c2f-4c01-758bf186e010@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=qiulaibin@huawei.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).