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

[Bart Van Assche <bvanassche@acm.org>]

On 12/16/24 6:40 PM, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.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@huawei.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.