From: Muchun Song <muchun.song@linux.dev>
To: Jens Axboe <axboe@kernel.dk>
Cc: Muchun Song <songmuchun@bytedance.com>,
Ming Lei <ming.lei@redhat.com>, Yu Kuai <yukuai1@huaweicloud.com>,
"open list:BLOCK LAYER" <linux-block@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 3/3] block: fix ordering between checking BLK_MQ_S_STOPPED and adding requests
Date: Wed, 11 Sep 2024 10:44:34 +0800 [thread overview]
Message-ID: <5F47D277-09E0-44FA-9EBB-D69786714A59@linux.dev> (raw)
In-Reply-To: <db5193e8-5b8e-46f9-bbfc-a1821217f5a6@kernel.dk>
> On Sep 10, 2024, at 21:22, Jens Axboe <axboe@kernel.dk> wrote:
>
> On 9/3/24 2:16 AM, Muchun Song wrote:
>> Supposing first scenario with a virtio_blk driver.
>>
>> CPU0 CPU1
>>
>> blk_mq_try_issue_directly()
>> __blk_mq_issue_directly()
>> q->mq_ops->queue_rq()
>> virtio_queue_rq()
>> blk_mq_stop_hw_queue()
>> virtblk_done()
>> blk_mq_request_bypass_insert() blk_mq_start_stopped_hw_queues()
>> /* Add IO request to dispatch list */ 1) store blk_mq_start_stopped_hw_queue()
>> clear_bit(BLK_MQ_S_STOPPED) 3) store
>> blk_mq_run_hw_queue() blk_mq_run_hw_queue()
>> if (!blk_mq_hctx_has_pending()) if (!blk_mq_hctx_has_pending()) 4) load
>> return return
>> blk_mq_sched_dispatch_requests() blk_mq_sched_dispatch_requests()
>> if (blk_mq_hctx_stopped()) 2) load if (blk_mq_hctx_stopped())
>> return return
>> __blk_mq_sched_dispatch_requests() __blk_mq_sched_dispatch_requests()
>>
>> Supposing another scenario.
>>
>> CPU0 CPU1
>>
>> blk_mq_requeue_work()
>> /* Add IO request to dispatch list */ 1) store virtblk_done()
>> blk_mq_run_hw_queues()/blk_mq_delay_run_hw_queues() blk_mq_start_stopped_hw_queues()
>> if (blk_mq_hctx_stopped()) 2) load blk_mq_start_stopped_hw_queue()
>> continue clear_bit(BLK_MQ_S_STOPPED) 3) store
>> blk_mq_run_hw_queue()/blk_mq_delay_run_hw_queue() blk_mq_run_hw_queue()
>> if (!blk_mq_hctx_has_pending()) 4) load
>> return
>> blk_mq_sched_dispatch_requests()
>>
>> Both scenarios are similar, the full memory barrier should be inserted between
>> 1) and 2), as well as between 3) and 4) to make sure that either CPU0 sees
>> BLK_MQ_S_STOPPED is cleared or CPU1 sees dispatch list. Otherwise, either CPU
>> will not rerun the hardware queue causing starvation of the request.
>>
>> The easy way to fix it is to add the essential full memory barrier into helper
>> of blk_mq_hctx_stopped(). In order to not affect the fast path (hardware queue
>> is not stopped most of the time), we only insert the barrier into the slow path.
>> Actually, only slow path needs to care about missing of dispatching the request
>> to the low-level device driver.
>
> Again, this is way too wide, it's unreadable.
OK. Will do.
Muchun,
Thanks.
>
> Patch looks fine, though.
>
> --
> Jens Axboe
next prev parent reply other threads:[~2024-09-11 2:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-03 8:16 [PATCH v2 0/3] Fix some starvation problems in block layer Muchun Song
2024-09-03 8:16 ` [PATCH v2 1/3] block: fix missing dispatching request when queue is started or unquiesced Muchun Song
2024-09-10 13:17 ` Jens Axboe
2024-09-11 2:43 ` Muchun Song
2024-09-03 8:16 ` [PATCH v2 2/3] block: fix ordering between checking QUEUE_FLAG_QUIESCED and adding requests Muchun Song
2024-09-04 12:56 ` Ming Lei
2024-09-10 13:22 ` Jens Axboe
2024-09-11 3:54 ` Ming Lei
2024-09-11 3:59 ` Muchun Song
2024-09-11 5:20 ` Muchun Song
2024-09-12 3:27 ` Muchun Song
2024-09-12 6:27 ` Muchun Song
2024-09-11 3:56 ` Muchun Song
2024-09-03 8:16 ` [PATCH v2 3/3] block: fix ordering between checking BLK_MQ_S_STOPPED " Muchun Song
2024-09-04 13:04 ` Ming Lei
2024-09-10 13:22 ` Jens Axboe
2024-09-11 2:44 ` Muchun Song [this message]
2024-09-10 2:49 ` [PATCH v2 0/3] Fix some starvation problems in block layer Muchun Song
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=5F47D277-09E0-44FA-9EBB-D69786714A59@linux.dev \
--to=muchun.song@linux.dev \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=songmuchun@bytedance.com \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®