From: Nilay Shroff <nilay@linux.ibm.com>
To: Yu Kuai <yukuai1@huaweicloud.com>,
axboe@kernel.dk, bvanassche@acm.org, ming.lei@redhat.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
yukuai3@huawei.com, yi.zhang@huawei.com, yangerkun@huawei.com,
johnny.chenyi@huawei.com
Subject: Re: [PATCH 7/7] blk-mq: add documentation for new queue attribute async_dpeth
Date: Thu, 2 Oct 2025 20:42:48 +0530 [thread overview]
Message-ID: <cbdb4a5a-a8ca-436b-a2ed-59f650a3dce7@linux.ibm.com> (raw)
In-Reply-To: <20250930071111.1218494-8-yukuai1@huaweicloud.com>
On 9/30/25 12:41 PM, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> Explain the attribute and the default value in different case.
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
> Documentation/ABI/stable/sysfs-block | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block
> index 0ed10aeff86b..09b9b3db9a1f 100644
> --- a/Documentation/ABI/stable/sysfs-block
> +++ b/Documentation/ABI/stable/sysfs-block
> @@ -609,6 +609,16 @@ Description:
> enabled, and whether tags are shared.
>
>
> +What: /sys/block/<disk>/queue/async_depth
> +Date: August 2025
> +Contact: linux-block@vger.kernel.org
> +Description:
> + [RW] This controls how many async requests may be allocated in the
> + block layer. If elevator is none, then this value is nr_requests.
> + By default, this value is 75% of nr_requests for bfq and kyber,
> + abd nr_requests for mq-deadline.
> +
Hmm, it seems we need to further elaborate above documentation, seeing the
way this new sysfs interface is playing out now for different I/O schedulers.
I'd suggest rewriting this as follow (you may further modify/simplify it based
on your taste, if needed):
Description:
[RW] Controls how many asynchronous requests may be allocated in the
block layer. The value is always capped at nr_requests.
When no elevator is active (none):
- async_depth is always equal to nr_requests.
For bfq scheduler:
- By default, async_depth is set to 75% of nr_requests.
Internal limits are then derived from this value:
* Sync writes: limited to async_depth (≈75% of nr_requests).
* Async I/O: limited to ~2/3 of async_depth (≈50% of nr_requests).
If a bfq_queue is weight-raised:
* Sync writes: limited to ~1/2 of async_depth (≈37% of nr_requests).
* Async I/O: limited to ~1/4 of async_depth (≈18% of nr_requests).
- If the user writes a custom value to async_depth, BFQ will recompute
these limits proportionally based on the new value.
For Kyber:
- By default async_depth is set to 75% of nr_requests.
- If the user writes a custom value to async_depth, then it override the
default and directly control the limit for writes and async I/O.
For mq-deadline:
- By default async_depth is set to nr_requests.
- If the user writes a custom value to async_depth, then it override the
default and directly control the limit for writes and async I/O.
Thanks,
--Nilay
next prev parent reply other threads:[~2025-10-02 15:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 7:11 [PATCH 0/7] blk-mq: introduce new queue attribute async_depth Yu Kuai
2025-09-30 7:11 ` [PATCH 1/7] block: convert nr_requests to unsigned int Yu Kuai
2025-10-02 15:13 ` Nilay Shroff
2025-09-30 7:11 ` [PATCH 2/7] blk-mq-sched: unify elevators checking for async requests Yu Kuai
2025-09-30 7:11 ` [PATCH 3/7] blk-mq: add a new queue sysfs attribute async_depth Yu Kuai
2025-10-02 15:10 ` Nilay Shroff
2025-10-06 1:57 ` Yu Kuai
2025-10-09 0:48 ` Yu Kuai
2025-10-09 6:42 ` Yu Kuai
2025-09-30 7:11 ` [PATCH 4/7] kyber: covert to use request_queue->async_depth Yu Kuai
2025-09-30 7:11 ` [PATCH 5/7] mq-deadline: " Yu Kuai
2025-10-02 18:56 ` Jeff Moyer
2025-09-30 7:11 ` [PATCH 6/7] block, bfq: convert " Yu Kuai
2025-09-30 7:11 ` [PATCH 7/7] blk-mq: add documentation for new queue attribute async_dpeth Yu Kuai
2025-10-02 15:12 ` Nilay Shroff [this message]
2025-10-06 2:00 ` Yu Kuai
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=cbdb4a5a-a8ca-436b-a2ed-59f650a3dce7@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=johnny.chenyi@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@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