Received-SPF: pass (google.com: domain of linux-kernel+bounces-125273-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <890bd06d-2a94-4138-9854-4a7ed74e0e51@acm.org>
Date: Fri, 29 Mar 2024 11:08:50 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] block/mq-deadline: Fix WARN when set async_depth by sysfs
To: Zhiguo Niu <zhiguo.niu@unisoc.com>, axboe@kernel.dk
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
 niuzhiguo84@gmail.com, ke.wang@unisoc.com, hongyu.jin@unisoc.com,
 Damien Le Moal <dlemoal@kernel.org>
References: <1711680261-5789-1-git-send-email-zhiguo.niu@unisoc.com>
Content-Language: en-US
From: Bart Van Assche <bvanassche@acm.org>
In-Reply-To: <1711680261-5789-1-git-send-email-zhiguo.niu@unisoc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3/28/24 7:44 PM, Zhiguo Niu wrote:
> diff --git a/block/mq-deadline.c b/block/mq-deadline.c
> index 02a916b..89c516e 100644
> --- a/block/mq-deadline.c
> +++ b/block/mq-deadline.c
> @@ -646,10 +646,12 @@ static void dd_depth_updated(struct blk_mq_hw_ctx *hctx)
>   	struct request_queue *q = hctx->queue;
>   	struct deadline_data *dd = q->elevator->elevator_data;
>   	struct blk_mq_tags *tags = hctx->sched_tags;
> +	unsigned int shift = tags->bitmap_tags.sb.shift;
> +	unsigned int dd_min_depth = max(1U, 3 * (1U << shift)  / 4);
>   
>   	dd->async_depth = max(1UL, 3 * q->nr_requests / 4);
>   
> -	sbitmap_queue_min_shallow_depth(&tags->bitmap_tags, dd->async_depth);
> +	sbitmap_queue_min_shallow_depth(&tags->bitmap_tags, dd_min_depth);
>   }

The above patch sets min_shallow_depth to the same value as commit
d47f9717e5cf ("block/mq-deadline: use correct way to throttling write
requests"). That commit got reverted because it was causing performance
problems. So the above patch reintroduces the performance problem that
has been fixed by commit 256aab46e316 ("Revert "block/mq-deadline: use
correct way to throttling write requests"").

Thank you for attempting to reintroduce a problem that just got fixed
without even mentioning that this is an attempt to reintroduce a
performance problem.

Bart.