From: Damien Le Moal <dlemoal@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Subject: Re: [PATCH v2 2/2] block: use a per disk workqueue for zone write plugging
Date: Tue, 23 Apr 2024 16:01:40 +1000 [thread overview]
Message-ID: <4b3a868a-3c79-42cd-96bb-3bf288ee786b@kernel.org> (raw)
In-Reply-To: <ZiYC6c100oNWFa0y@infradead.org>
On 2024/04/22 16:25, Christoph Hellwig wrote:
> On Sat, Apr 20, 2024 at 04:58:11PM +0900, Damien Le Moal wrote:
>> A zone write plug BIO work function blk_zone_wplug_bio_work() calls
>> submit_bio_noacct_nocheck() to execute the next unplugged BIO. This
>> function may block. So executing zone plugs BIO works using the block
>> layer global kblockd workqueue can potentially lead to preformance or
>> latency issues as the number of concurrent work for a workqueue is
>> limited to WQ_DFL_ACTIVE (256).
>> 1) For a system with a large number of zoned disks, issuing write
>> requests to otherwise unused zones may be delayed wiating for a work
>> thread to become available.
>> 2) Requeue operations which use kblockd but are independent of zone
>> write plugging may alsoi end up being delayed.
>>
>> To avoid these potential performance issues, create a workqueue per
>> zoned device to execute zone plugs BIO work. The workqueue max active
>> parameter is set to the maximum number of zone write plugs allocated
>> with the zone write plug mempool. This limit is equal to the maximum
>> number of open zones of the disk and defaults to 128 for disks that do
>> not have a limit on the number of open zones.
>
> Looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> Should the zone write plug submission do non-blocking submissions as well
> to avoid stalling in the workqueue thread all the time?
I do not think that the stalling actually happens that often. The 2 main cases I
see are:
1) Out of tag so we block on tag allocation when preparing the request in
submit_bio_noacct_nocheck(), or
2) The device has BLK_MQ_F_BLOCKING set for its tag set (e.g. nullblk with
memory backing).
For (1), we could use RQF_NOWAIT to prevent blocking, but then we would need to
retry later on with a timer to make forward progress for the plug. And I do not
think we can actually avoid (2). So in the end, I do not see a clean way to
completely avoid blocking in all cases.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2024-04-23 6:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 7:58 [PATCH v2 0/2] Fixes for zone write plugging Damien Le Moal
2024-04-20 7:58 ` [PATCH v2 1/2] block: prevent freeing a zone write plug too early Damien Le Moal
2024-04-22 6:23 ` Christoph Hellwig
2024-04-23 6:12 ` Damien Le Moal
2024-04-23 14:21 ` Jens Axboe
2024-04-23 15:16 ` Damien Le Moal
2024-04-23 15:36 ` Jens Axboe
2024-04-23 18:19 ` Damien Le Moal
2024-04-24 13:58 ` Jens Axboe
2024-04-20 7:58 ` [PATCH v2 2/2] block: use a per disk workqueue for zone write plugging Damien Le Moal
2024-04-22 6:25 ` Christoph Hellwig
2024-04-23 6:01 ` Damien Le Moal [this message]
2024-04-23 15:46 ` (subset) [PATCH v2 0/2] Fixes " 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=4b3a868a-3c79-42cd-96bb-3bf288ee786b@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
/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.