| 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
| ||
|
Message-Id: <20230219104309.1511562-13-shikemeng@huaweicloud.com>
Date: Sun, 19 Feb 2023 18:43:04 +0800
From: Kemeng Shi <shikemeng@...weicloud.com>
To: paolo.valente@...aro.org, axboe@...nel.dk, jack@...e.cz
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
shikemeng@...weicloud.com
Subject: [PATCH 12/17] block, bfq: define and use soft_rt, in_burst and wr_or_deserves_wr only low_latency is enable
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@...weicloud.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
Powered by blists - more mailing lists