From:   Kemeng Shi <shikemeng@huaweicloud.com>
To:     paolo.valente@linaro.org, axboe@kernel.dk, jack@suse.cz
Cc:     linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        shikemeng@huaweicloud.com
Subject: [PATCH 12/17] block, bfq: define and use soft_rt, in_burst and wr_or_deserves_wr only low_latency is enable
Date:   Sun, 19 Feb 2023 18:43:04 +0800
Message-Id: <20230219104309.1511562-13-shikemeng@huaweicloud.com>
In-Reply-To: <20230219104309.1511562-1-shikemeng@huaweicloud.com>
References: <20230219104309.1511562-1-shikemeng@huaweicloud.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

The soft_rt, in_burst and wr_or_deserves_wr are only used when low_latency
is enable. Currently, these variables are computed even low_latency is
disable. Define these variables in successful branch of bfqd->low_latency
check and compute them if needed to remove redundant computation and
improve readability.
The interactive parameter will be used only if low_latency is enabled
outside bfq_bfqq_handle_idle_busy_switch, so it's safe to move
interactive assignment inside branch where low_latency is true.

Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
 block/bfq-iosched.c | 81 +++++++++++++++++++++++----------------------
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index a8cb0a0d36f3..eda6669d0571 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1828,8 +1828,7 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
 					     struct request *rq,
 					     bool *interactive)
 {
-	bool soft_rt, in_burst,	wr_or_deserves_wr,
-		bfqq_wants_to_preempt,
+	bool bfqq_wants_to_preempt,
 		idle_for_long_time = bfq_bfqq_idle_for_long_time(bfqd, bfqq),
 		/*
 		 * See the comments on
@@ -1840,43 +1839,6 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
 			bfqq->ttime.last_end_request +
 			bfqd->bfq_slice_idle * 3;
 	unsigned int act_idx = bfq_actuator_index(bfqd, rq->bio);
-	bool bfqq_non_merged_or_stably_merged =
-		bfqq->bic || RQ_BIC(rq)->bfqq_data[act_idx].stably_merged;
-
-	/*
-	 * bfqq deserves to be weight-raised if:
-	 * - it is sync,
-	 * - it does not belong to a large burst,
-	 * - it has been idle for enough time or is soft real-time,
-	 * - is linked to a bfq_io_cq (it is not shared in any sense),
-	 * - has a default weight (otherwise we assume the user wanted
-	 *   to control its weight explicitly)
-	 */
-	in_burst = bfq_bfqq_in_large_burst(bfqq);
-	soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 &&
-		!BFQQ_TOTALLY_SEEKY(bfqq) &&
-		!in_burst &&
-		time_is_before_jiffies(bfqq->soft_rt_next_start) &&
-		bfqq->dispatched == 0 &&
-		bfqq->entity.new_weight == 40;
-	*interactive = !in_burst && idle_for_long_time &&
-		bfqq->entity.new_weight == 40;
-	/*
-	 * Merged bfq_queues are kept out of weight-raising
-	 * (low-latency) mechanisms. The reason is that these queues
-	 * are usually created for non-interactive and
-	 * non-soft-real-time tasks. Yet this is not the case for
-	 * stably-merged queues. These queues are merged just because
-	 * they are created shortly after each other. So they may
-	 * easily serve the I/O of an interactive or soft-real time
-	 * application, if the application happens to spawn multiple
-	 * processes. So let also stably-merged queued enjoy weight
-	 * raising.
-	 */
-	wr_or_deserves_wr = bfqd->low_latency &&
-		(bfqq->wr_coeff > 1 ||
-		 (bfq_bfqq_sync(bfqq) && bfqq_non_merged_or_stably_merged &&
-		  (*interactive || soft_rt)));
 
 	/*
 	 * Using the last flag, update budget and check whether bfqq
@@ -1911,6 +1873,24 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
 	bfq_clear_bfqq_just_created(bfqq);
 
 	if (bfqd->low_latency) {
+		bool soft_rt, in_burst,	wr_or_deserves_wr;
+		bool bfqq_non_merged_or_stably_merged =
+			bfqq->bic ||
+			RQ_BIC(rq)->bfqq_data[act_idx].stably_merged;
+
+		/*
+		 * bfqq deserves to be weight-raised if:
+		 * - it is sync,
+		 * - it does not belong to a large burst,
+		 * - it has been idle for enough time or is soft real-time,
+		 * - is linked to a bfq_io_cq (it is not shared in any sense),
+		 * - has a default weight (otherwise we assume the user wanted
+		 *   to control its weight explicitly)
+		 */
+		in_burst = bfq_bfqq_in_large_burst(bfqq);
+		*interactive = !in_burst && idle_for_long_time &&
+			bfqq->entity.new_weight == 40;
+
 		if (unlikely(time_is_after_jiffies(bfqq->split_time)))
 			/* wraparound */
 			bfqq->split_time =
@@ -1918,6 +1898,29 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
 
 		if (time_is_before_jiffies(bfqq->split_time +
 					   bfqd->bfq_wr_min_idle_time)) {
+			soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 &&
+				!BFQQ_TOTALLY_SEEKY(bfqq) &&
+				!in_burst &&
+				time_is_before_jiffies(bfqq->soft_rt_next_start) &&
+				bfqq->dispatched == 0 &&
+				bfqq->entity.new_weight == 40;
+			/*
+			 * Merged bfq_queues are kept out of weight-raising
+			 * (low-latency) mechanisms. The reason is that these queues
+			 * are usually created for non-interactive and
+			 * non-soft-real-time tasks. Yet this is not the case for
+			 * stably-merged queues. These queues are merged just because
+			 * they are created shortly after each other. So they may
+			 * easily serve the I/O of an interactive or soft-real time
+			 * application, if the application happens to spawn multiple
+			 * processes. So let also stably-merged queued enjoy weight
+			 * raising.
+			 */
+			wr_or_deserves_wr = (bfqq->wr_coeff > 1 ||
+				(bfq_bfqq_sync(bfqq) &&
+				bfqq_non_merged_or_stably_merged &&
+				(*interactive || soft_rt)));
+
 			bfq_update_bfqq_wr_on_rq_arrival(bfqd, bfqq,
 							 old_wr_coeff,
 							 wr_or_deserves_wr,
-- 
2.30.0