linux-kernel - Re: [PATCH RESEND] block/mq-deadline: adjust the timeout period of the per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <836230c2-44d6-45e3-a25b-0ec5d56c5f7a@kernel.org>
Date: Fri, 3 Oct 2025 13:17:05 +0900
From: Damien Le Moal <dlemoal@...nel.org>
To: chengkaitao <pilgrimtao@...il.com>, axboe@...nel.dk
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
 chengkaitao <chengkaitao@...inos.cn>
Subject: Re: [PATCH RESEND] block/mq-deadline: adjust the timeout period of
 the per_prio->dispatch

On 9/26/25 11:38, chengkaitao wrote:
> From: chengkaitao <chengkaitao@...inos.cn>
> 
> Reference function started_after()

What does this mean ?

> Before modification:
> 	Timeout for dispatch{read}: 9.5s
> 	started_after - 0.5s < latest_start - 10s
> 	9.5s < latest_start - started_after
> 
> 	Timeout for dispatch{write}: 5s
> 	started_after - 5s < latest_start - 10s
> 	5s < latest_start - started_after
> 
> At this point, write requests have higher priority than read requests.
> 
> After modification:
> 	Timeout for dispatch{read/write}: 5s
> 	prio_aging_expire / 2 < latest_start - started_after

This is extremely hard to parse and understand. Can you please make full
sentences that explain what the problem is, and for your example, the starting
situation/state you are in ? E.g "If there are a lot of request inserted at
head, then ... Blah"

Also, in the title, s/timeout period/timeout

> Signed-off-by: chengkaitao <chengkaitao@...inos.cn>
> ---
>  block/mq-deadline.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/block/mq-deadline.c b/block/mq-deadline.c
> index b9b7cdf1d3c9..f311168f8dfe 100644
> --- a/block/mq-deadline.c
> +++ b/block/mq-deadline.c
> @@ -672,7 +672,8 @@ static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq,
>  
>  	if (flags & BLK_MQ_INSERT_AT_HEAD) {
>  		list_add(&rq->queuelist, &per_prio->dispatch);
> -		rq->fifo_time = jiffies;
> +		rq->fifo_time = jiffies + dd->fifo_expire[data_dir]
> +				- dd->prio_aging_expire / 2;

The request is inserted to the dispatch list directly here. So why do we need to
change the timeout to switch to fifo ? Your commit message does not explain that
at all, and I do not see a trivial explanation for it myself. Please clarify.
I suspect that you have a situation where you see a lot of requeue at head and
that completely skew the fifo/prio aging ? I am memrely guessing here. Please
resend your patch with a clear commit message, and also a comment for the change
above explaining what is being done.

>  	} else {
>  		deadline_add_rq_rb(per_prio, rq);
>  

-- 
Damien Le Moal
Western Digital Research