linux-kernel - Re: [PATCH v2 3/4] block/elevator: choose none elevator for high IO concurrency ability disk

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ac5aa72f-9944-4436-bed3-43e4e4e97f5e@acm.org>
Date: Tue, 17 Dec 2024 13:50:39 -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 v2 3/4] block/elevator: choose none elevator for high IO
 concurrency ability disk

On 12/16/24 6:40 PM, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@...wei.com>
> 
> The maximal default nr_requests is 256, and if disk can handle more than
> 256 requests concurrently, use elevator in this case is useless, on the
> one hand it limits the number of requests to 256, on the other hand,
> it can't merge or sort IO because requests are dispatched to disk
> immediately and the elevator is just empty.
> 
> For example, for nvme megaraid with 512 queue_depth by default, we have
> to change default elevator to none, otherwise deadline will lose a lot of
> performance.
> 
> Signed-off-by: Yu Kuai <yukuai3@...wei.com>
> ---
>   block/elevator.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/block/elevator.c b/block/elevator.c
> index 7c3ba80e5ff4..4cce1e7c47d5 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -568,6 +568,17 @@ static struct elevator_type *elevator_get_default(struct request_queue *q)
>   	    !blk_mq_is_shared_tags(q->tag_set->flags))
>   		return NULL;
>   
> +	/*
> +	 * If nr_queues will be less than disk ability, requests will be
> +	 * dispatched to disk immediately, it's useless to use elevator. User
> +	 * should set a bigger nr_requests or limit disk ability manually if
> +	 * they really want to use elevator.
> +	 */
> +	if (q->queue_depth && q->queue_depth >= BLKDEV_DEFAULT_RQ * 2)
> +		return NULL;
> +	if (!q->queue_depth && q->tag_set->queue_depth >= BLKDEV_DEFAULT_RQ * 2)
> +		return NULL;
> +
>   	return elevator_find_get("mq-deadline");
>   }

Shouldn't this patch be submitted separately since it is independent of
the rest of the patches in this series?

Thanks,

Bart.