[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <da924dc3-a2e5-4bfe-afb6-5fbc55bc25a3@acm.org>
Date: Tue, 17 Dec 2024 14:13:06 -0800
From: Bart Van Assche <bvanassche@....org>
To: Yu Kuai <yukuai1@...weicloud.com>, axboe@...nel.dk,
akpm@...ux-foundation.org, ming.lei@...hat.com, yang.yang@...o.com,
osandov@...com, paolo.valente@...aro.org
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
yukuai3@...wei.com, yi.zhang@...wei.com, yangerkun@...wei.com
Subject: Re: [PATCH RFC v2 4/4] block/mq-deadline: introduce min_async_depth
On 12/16/24 6:40 PM, Yu Kuai wrote:
> +static unsigned int min_async_depth = 64;
> +module_param(min_async_depth, int, 0444);
> +MODULE_PARM_DESC(min_async_depth, "The minimal number of tags available for asynchronous requests");
Users may not like it that this parameter is read-only.
> @@ -513,9 +523,12 @@ static void dd_depth_updated(struct blk_mq_hw_ctx *hctx)
> struct deadline_data *dd = q->elevator->elevator_data;
> struct blk_mq_tags *tags = hctx->sched_tags;
>
> - dd->async_depth = max(1UL, 3 * q->nr_requests / 4);
Shouldn't this assignment be retained instead of removing it?
Additionally, some time ago a user requested to initialize
dd->async_depth to q->nr_requests instead of 3/4 of that value because
the lower value introduced a performance regression.
Thanks,
Bart.
Powered by blists - more mailing lists