Hi, this series contain some patches to improve in-service queue
preemption, protect max_budget updating race between configuration
and auto-tuning and so on. More details can be found in respective
log message. Thanks!
Kemeng Shi (17):
block, bfq: properly mark bfqq remained idle
block, bfq: try preemption if bfqq has higher weight and the same
priority class
block, bfq: only preempt plugged in_service_queue if
bfq_better_to_idle say no
block, bfq: recover the "service hole" if enough budget is left
block, bfq: Update bfqd->max_budget with bfqd->lock held
block, bfq: correct bfq_max_budget and bfq_min_budget
block, bfq: correct interactive weight-raise check in
bfq_set_budget_timeout
block, bfq: start service_from_wr accumulating of async queues
correctly
block, bfq: stop to detect queue as waker queue if it already is now
block, bfq: fix typo in comment
block, bfq: simpfy computation of bfqd->budgets_assigned
block, bfq: define and use soft_rt, in_burst and wr_or_deserves_wr
only low_latency is enable
block, bfq: remove unnecessary "wr" part of wr_or_deserves_wr
block, bfq: remove redundant oom_bfqq check for bfqq from
bfq_find_close_cooperator
block, bfq: some cleanups for function bfq_pos_tree_add_move
block, bfq: remove unnecessary goto tag in __bfq_weights_tree_remove
block, bfq: remove unnecessary local variable __bfqq in
bfq_setup_merge
block/bfq-iosched.c | 176 +++++++++++++++++++++++---------------------
block/bfq-wf2q.c | 2 +-
2 files changed, 95 insertions(+), 83 deletions(-)
--
2.30.0
We will compare priority class and weight of current bfqq with
in_service_queue to check if bfqq could preempt in_service_queue.
Currently we will try to preempt in_service_queue if bfqq has higher
weight than in_service_queue even with lower priority class. Actually,
we will only serve bfqq with higher priority class (see
bfq_lookup_next_entity), so bfqq with higher weight and lower priority
class will not be a candidate to preempt in_service_queue.
Compare weight of bfqqs with the same priority in
bfq_bfqq_higher_class_or_weight to make preemption check more reasonable.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 3f5c740664ce..4868538c9745 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1768,6 +1768,10 @@ static bool bfq_bfqq_higher_class_or_weight(struct bfq_queue *bfqq,
if (bfqq->ioprio_class < in_serv_bfqq->ioprio_class)
return true;
+ /* only try weight comparison with same priority class */
+ if (bfqq->ioprio_class != in_serv_bfqq->ioprio_class)
+ return false;
+
if (in_serv_bfqq->entity.parent == bfqq->entity.parent) {
bfqq_weight = bfqq->entity.weight;
in_serv_weight = in_serv_bfqq->entity.weight;
--
2.30.0
bfq_max_budget and bfq_user_max_budget maybe be in inconsisten state if
bfq_max_budget configuration and bfq_max_budget auto-update happen
concurrently.
Example sequence:
config auto-update
bfqd->bfq_max_budget =
__data
if (bfqd->bfq_user_max_budget == 0)
bfqd->bfq_max_budget =
bfq_calc_max_budget(bfqd);
bfqd->bfq_user_max_budget =
__data;
Users may set bfq_max_budget successfully while read a different value
from they set.
bfq_max_budget is only update in update_thr_responsiveness_params and
configuration code. As update_thr_responsiveness_params is always called
under bfqd->lock, fix this by holding lock in configuration code.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index edbf5c9aeb47..5b08711cbaf6 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -7489,6 +7489,7 @@ static ssize_t bfq_max_budget_store(struct elevator_queue *e,
if (ret)
return ret;
+ spin_lock_irq(&bfqd->lock);
if (__data == 0)
bfqd->bfq_max_budget = bfq_calc_max_budget(bfqd);
else {
@@ -7498,6 +7499,7 @@ static ssize_t bfq_max_budget_store(struct elevator_queue *e,
}
bfqd->bfq_user_max_budget = __data;
+ spin_unlock_irq(&bfqd->lock);
return count;
}
@@ -7523,8 +7525,11 @@ static ssize_t bfq_timeout_sync_store(struct elevator_queue *e,
__data = INT_MAX;
bfqd->bfq_timeout = msecs_to_jiffies(__data);
+
+ spin_lock_irq(&bfqd->lock);
if (bfqd->bfq_user_max_budget == 0)
bfqd->bfq_max_budget = bfq_calc_max_budget(bfqd);
+ spin_unlock_irq(&bfqd->lock);
return count;
}
--
2.30.0
For case that user set a max_budget, we should use bfq_max_budget
set by user instead of bfq_default_max_budget when budgets_assigned
is not enough to compulte auto-tuning max_budget.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 5b08711cbaf6..b32bae5259d5 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1458,7 +1458,8 @@ static int bfq_bfqq_budget_left(struct bfq_queue *bfqq)
*/
static int bfq_max_budget(struct bfq_data *bfqd)
{
- if (bfqd->budgets_assigned < bfq_stats_min_budgets)
+ if (bfqd->budgets_assigned < bfq_stats_min_budgets &&
+ bfqd->bfq_user_max_budget == 0)
return bfq_default_max_budget;
else
return bfqd->bfq_max_budget;
@@ -1470,7 +1471,8 @@ static int bfq_max_budget(struct bfq_data *bfqd)
*/
static int bfq_min_budget(struct bfq_data *bfqd)
{
- if (bfqd->budgets_assigned < bfq_stats_min_budgets)
+ if (bfqd->budgets_assigned < bfq_stats_min_budgets &&
+ bfqd->bfq_user_max_budget == 0)
return bfq_default_max_budget / 32;
else
return bfqd->bfq_max_budget / 32;
--
2.30.0
Start accumulating service_from_wr when async queues are weight raised.
The service_from_wr for async queues is accumulated and checked to finish
weight-raise as sync queues. We need charge service_from_wr for async
queues or service_from_wr will keep accumulating and async queues will
finish weight-raise soon after weight-raise starts.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 5610a7dcacdf..7a0283f08aed 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2323,6 +2323,7 @@ static void bfq_add_request(struct request *rq)
time_is_before_jiffies(
bfqq->last_wr_start_finish +
bfqd->bfq_wr_min_inter_arr_async)) {
+ bfqq->service_from_wr = 0;
bfqq->wr_coeff = bfqd->bfq_wr_coeff;
bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);
--
2.30.0
If budget left is less than budget need by next request, the activated bfqq
will be expired if it preempts the in-service queue. Avoid to cause useless
overhead to check budget left is enough for next request.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 7b416f9471b3..edbf5c9aeb47 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1588,13 +1588,15 @@ static bool bfq_bfqq_update_budg_for_activation(struct bfq_data *bfqd,
/*
* In the next compound condition, we check also whether there
- * is some budget left, because otherwise there is no point in
- * trying to go on serving bfqq with this same budget: bfqq
- * would be expired immediately after being selected for
- * service. This would only cause useless overhead.
+ * is some budget left for next request to serve, because
+ * otherwise there is no point in trying to go on serving bfqq
+ * with this same budget: bfqq would be expired immediately
+ * after being selected for service. This would only cause
+ * useless overhead.
*/
if (bfq_bfqq_non_blocking_wait_rq(bfqq) && arrived_in_time &&
- bfq_bfqq_budget_left(bfqq) > 0) {
+ bfq_bfqq_budget_left(bfqq) >=
+ bfq_serv_to_charge(bfqq->next_rq, bfqq)) {
/*
* We do not clear the flag non_blocking_wait_rq here, as
* the latter is used in bfq_activate_bfqq to signal
--
2.30.0
Bfqq activation will try to recover the "service hole" of bfqq which may
issues requests greedily while remained idle for other reasons: CPU high
load, bfqq not enjoying idling, I/O throttling somewhere in the path from
the process to the I/O scheduler. So we should mark bfqq remained idle
when expired for two reasons: BFQQE_NO_MORE_REQUESTS or BFQQE_TOO_IDLE.
More details can be found in comment of
bfq_bfqq_update_budg_for_activation.
So we should mark bfqq remained idle expired for BFQQE_NO_MORE_REQUESTS
or BFQQE_TOO_IDLE instead of (reason != BFQQE_BUDGET_TIMEOUT &&
reason != BFQQE_BUDGET_EXHAUSTED).
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 777dcab73c8e..3f5c740664ce 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -4420,8 +4420,8 @@ void bfq_bfqq_expire(struct bfq_data *bfqd,
/* mark bfqq as waiting a request only if a bic still points to it */
if (!bfq_bfqq_busy(bfqq) &&
- reason != BFQQE_BUDGET_TIMEOUT &&
- reason != BFQQE_BUDGET_EXHAUSTED) {
+ reason == BFQQE_NO_MORE_REQUESTS &&
+ reason == BFQQE_TOO_IDLE) {
bfq_mark_bfqq_non_blocking_wait_rq(bfqq);
/*
* Not setting service to 0, because, if the next rq
--
2.30.0
After weight-raise finished, bfqq->wr_coeff is reset to 1 while
bfqq->wr_cur_max_time may not be reset. For example,
Function bfq_update_bfqq_wr_on_rq_arrival will only reset wr_coeff to 1 if
bfqq is created in burst creation. Function bfq_set_budget_timeout will be
called when bfqq is selected while it's wr_cur_max_time is set and wr_coeff
is 1. Fix this by check wr_coeff > 1 along with check wr_cur_max_time
check like other code do.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index b32bae5259d5..5610a7dcacdf 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3297,7 +3297,8 @@ static void bfq_set_budget_timeout(struct bfq_data *bfqd,
{
unsigned int timeout_coeff;
- if (bfqq->wr_cur_max_time == bfqd->bfq_wr_rt_max_time)
+ if (bfqq->wr_coeff > 1 &&
+ bfqq->wr_cur_max_time == bfqd->bfq_wr_rt_max_time)
timeout_coeff = 1;
else
timeout_coeff = bfqq->entity.weight / bfqq->entity.orig_weight;
--
2.30.0
If last_completed_rq_bfqq is the current waker queue of bfqq, it's no
meaning to execute the detection logic as nothing will change whether
detection successes or fails.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 7a0283f08aed..0a11a381ee7d 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2147,7 +2147,8 @@ static void bfq_check_waker(struct bfq_data *bfqd, struct bfq_queue *bfqq,
bfq_bfqq_has_short_ttime(bfqq) ||
now_ns - bfqd->last_completion >= 4 * NSEC_PER_MSEC ||
bfqd->last_completed_rq_bfqq == &bfqd->oom_bfqq ||
- bfqq == &bfqd->oom_bfqq)
+ bfqq == &bfqd->oom_bfqq ||
+ bfqd->last_completed_rq_bfqq == bfqq->waker_bfqq)
return;
/*
--
2.30.0
IO/ -> I/O
bfq_fqq_update_budg_for_activation -> bfq_bfqq_update_budg_for_activation
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 2 +-
block/bfq-wf2q.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 0a11a381ee7d..2559343593bb 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5734,7 +5734,7 @@ bfq_do_early_stable_merge(struct bfq_data *bfqd, struct bfq_queue *bfqq,
*
* Putting these two facts together, this commits merges stably the
* bfq_queues associated with these I/O flows, i.e., with the
- * processes that generate these IO/ flows, regardless of how many the
+ * processes that generate these I/O flows, regardless of how many the
* involved processes are.
*
* To decide whether a set of bfq_queues is actually associated with
diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c
index 7941b6f07391..1b8d05bae116 100644
--- a/block/bfq-wf2q.c
+++ b/block/bfq-wf2q.c
@@ -931,7 +931,7 @@ static void __bfq_activate_entity(struct bfq_entity *entity,
bool backshifted = false;
unsigned long long min_vstart;
- /* See comments on bfq_fqq_update_budg_for_activation */
+ /* See comments on bfq_bfqq_update_budg_for_activation */
if (non_blocking_wait_rq && bfq_gt(st->vtime, entity->finish)) {
backshifted = true;
min_vstart = entity->finish;
--
2.30.0
The computation of budgets_assigned is a little confusing as we only need
to check if it's updated more than 10 times. Simpfy the computation to
improve readability.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 2559343593bb..a8cb0a0d36f3 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -175,7 +175,7 @@ static const int bfq_back_penalty = 2;
static u64 bfq_slice_idle = NSEC_PER_SEC / 125;
/* Minimum number of assigned budgets for which stats are safe to compute. */
-static const int bfq_stats_min_budgets = 194;
+static const int bfq_stats_min_budgets = 11;
/* Default maximum budget values, in sectors and number of requests. */
static const int bfq_default_max_budget = 16 * 1024;
@@ -3317,7 +3317,7 @@ static void __bfq_set_in_service_queue(struct bfq_data *bfqd,
if (bfqq) {
bfq_clear_bfqq_fifo_expire(bfqq);
- bfqd->budgets_assigned = (bfqd->budgets_assigned * 7 + 256) / 8;
+ bfqd->budgets_assigned++;
if (time_is_before_jiffies(bfqq->last_wr_start_finish) &&
bfqq->wr_coeff > 1 &&
--
2.30.0
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 <[email protected]>
---
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
The oom_bfqq is never added to tree in bfq_pos_tree_add_move, so bfqq
returned from bfq_find_close_cooperator is no need to be checked if it's
oom_bfqq.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 6a8ea9a451cc..ee02c7502394 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3038,8 +3038,7 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
new_bfqq = bfq_find_close_cooperator(bfqd, bfqq,
bfq_io_struct_pos(io_struct, request));
- if (new_bfqq && likely(new_bfqq != &bfqd->oom_bfqq) &&
- bfq_may_be_close_cooperator(bfqq, new_bfqq))
+ if (new_bfqq && bfq_may_be_close_cooperator(bfqq, new_bfqq))
return bfq_setup_merge(bfqq, new_bfqq);
return NULL;
--
2.30.0
Do free work if num_active == 0 and remove unnecessary tag
reset_entity_pointer.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 6ba096e9aec6..2705a24ab146 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -976,13 +976,11 @@ void bfq_weights_tree_remove(struct bfq_queue *bfqq)
root = &bfqq->bfqd->queue_weights_tree;
bfqq->weight_counter->num_active--;
- if (bfqq->weight_counter->num_active > 0)
- goto reset_entity_pointer;
-
- rb_erase_cached(&bfqq->weight_counter->weights_node, root);
- kfree(bfqq->weight_counter);
+ if (bfqq->weight_counter->num_active == 0) {
+ rb_erase_cached(&bfqq->weight_counter->weights_node, root);
+ kfree(bfqq->weight_counter);
+ }
-reset_entity_pointer:
bfqq->weight_counter = NULL;
bfq_put_queue(bfqq);
}
--
2.30.0
We could traversal bfqq->new_bfqq list without a local variable easily and
intuitively. So remove unnecessary local variable __bfqq.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 2705a24ab146..037f73a25567 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -2752,7 +2752,6 @@ static struct bfq_queue *
bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq)
{
int process_refs, new_process_refs;
- struct bfq_queue *__bfqq;
/*
* If there are no process references on the new_bfqq, then it is
@@ -2764,10 +2763,9 @@ bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq)
return NULL;
/* Avoid a circular list and skip interim queue merges. */
- while ((__bfqq = new_bfqq->new_bfqq)) {
- if (__bfqq == bfqq)
+ while ((new_bfqq = new_bfqq->new_bfqq)) {
+ if (new_bfqq == bfqq)
return NULL;
- new_bfqq = __bfqq;
}
process_refs = bfqq_process_refs(bfqq);
--
2.30.0
There are three cleanups in this patch:
1. The oom_bfqq is never inserted to tree, so return immediately for
oom_bfqq before unnecessary NULL check of bfqq->pos_root.
2. Only set bfqq->pos_root after bfq_rq_pos_tree_lookup successes rather
than set bfqq->pos_root unconditionally and reset to NULL if
bfq_rq_pos_tree_lookup fails.
3. Remove unnecessary local variable __bfqq which is only used to check
return value of bfq_rq_pos_tree_lookup.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index ee02c7502394..6ba096e9aec6 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -783,17 +783,16 @@ void __cold
bfq_pos_tree_add_move(struct bfq_data *bfqd, struct bfq_queue *bfqq)
{
struct rb_node **p, *parent;
- struct bfq_queue *__bfqq;
+
+ /* oom_bfqq does not participate in queue merging */
+ if (bfqq == &bfqd->oom_bfqq)
+ return;
if (bfqq->pos_root) {
rb_erase(&bfqq->pos_node, bfqq->pos_root);
bfqq->pos_root = NULL;
}
- /* oom_bfqq does not participate in queue merging */
- if (bfqq == &bfqd->oom_bfqq)
- return;
-
/*
* bfqq cannot be merged any longer (see comments in
* bfq_setup_cooperator): no point in adding bfqq into the
@@ -807,14 +806,13 @@ bfq_pos_tree_add_move(struct bfq_data *bfqd, struct bfq_queue *bfqq)
if (!bfqq->next_rq)
return;
+ if (bfq_rq_pos_tree_lookup(bfqd, &bfqq_group(bfqq)->rq_pos_tree,
+ blk_rq_pos(bfqq->next_rq), &parent, &p))
+ return;
+
bfqq->pos_root = &bfqq_group(bfqq)->rq_pos_tree;
- __bfqq = bfq_rq_pos_tree_lookup(bfqd, bfqq->pos_root,
- blk_rq_pos(bfqq->next_rq), &parent, &p);
- if (!__bfqq) {
- rb_link_node(&bfqq->pos_node, parent, p);
- rb_insert_color(&bfqq->pos_node, bfqq->pos_root);
- } else
- bfqq->pos_root = NULL;
+ rb_link_node(&bfqq->pos_node, parent, p);
+ rb_insert_color(&bfqq->pos_node, bfqq->pos_root);
}
/*
--
2.30.0
Before commit 96a291c38c3299 ("block, bfq: preempt lower-weight or
lower-priority queues"), wr_or_deserves_wr is used to check if
preempt is wanted. Currently, wr_or_deserves_wr is only used in
bfq_update_bfqq_wr_on_rq_arrival to check if weight raising is
needed, so the "wr" part of wr_or_deserves_wr is not needed
anymore. Rename wr_or_deserves_wr to deserves_wr and remove
unnecessary bfqq->wr_coeff > 1 for original wr_or_deserves_wr.
Signed-off-by: Kemeng Shi <[email protected]>
---
block/bfq-iosched.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index eda6669d0571..6a8ea9a451cc 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1656,12 +1656,12 @@ static unsigned long bfq_smallest_from_now(void)
static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd,
struct bfq_queue *bfqq,
unsigned int old_wr_coeff,
- bool wr_or_deserves_wr,
+ bool deserves_wr,
bool interactive,
bool in_burst,
bool soft_rt)
{
- if (old_wr_coeff == 1 && wr_or_deserves_wr) {
+ if (old_wr_coeff == 1 && deserves_wr) {
/* start a weight-raising period */
if (interactive) {
bfqq->service_from_wr = 0;
@@ -1873,7 +1873,7 @@ 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 soft_rt, in_burst, deserves_wr;
bool bfqq_non_merged_or_stably_merged =
bfqq->bic ||
RQ_BIC(rq)->bfqq_data[act_idx].stably_merged;
@@ -1916,14 +1916,13 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
* processes. So let also stably-merged queued enjoy weight
* raising.
*/
- wr_or_deserves_wr = (bfqq->wr_coeff > 1 ||
- (bfq_bfqq_sync(bfqq) &&
+ deserves_wr = (bfq_bfqq_sync(bfqq) &&
bfqq_non_merged_or_stably_merged &&
- (*interactive || soft_rt)));
+ (*interactive || soft_rt));
bfq_update_bfqq_wr_on_rq_arrival(bfqd, bfqq,
old_wr_coeff,
- wr_or_deserves_wr,
+ deserves_wr,
*interactive,
in_burst,
soft_rt);
--
2.30.0
Hi Kemeng,
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kemeng-Shi/block-bfq-properly-mark-bfqq-remained-idle/20230219-104312
base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next
patch link: https://lore.kernel.org/r/20230219104309.1511562-18-shikemeng%40huaweicloud.com
patch subject: [PATCH 17/17] block, bfq: remove unnecessary local variable __bfqq in bfq_setup_merge
config: openrisc-randconfig-m041-20230219 (https://download.01.org/0day-ci/archive/20230220/[email protected]/config)
compiler: or1k-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
| Reported-by: Dan Carpenter <[email protected]>
| Link: https://lore.kernel.org/r/[email protected]/
New smatch warnings:
block/bfq-iosched.c:2785 bfq_setup_merge() error: we previously assumed 'new_bfqq' could be null (see line 2766)
Old smatch warnings:
block/bfq-iosched.c:6195 __bfq_insert_request() warn: variable dereferenced before check 'bfqq' (see line 6191)
vim +/new_bfqq +2785 block/bfq-iosched.c
36eca894832351 Arianna Avanzini 2017-04-12 2751 static struct bfq_queue *
36eca894832351 Arianna Avanzini 2017-04-12 2752 bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq)
36eca894832351 Arianna Avanzini 2017-04-12 2753 {
36eca894832351 Arianna Avanzini 2017-04-12 2754 int process_refs, new_process_refs;
36eca894832351 Arianna Avanzini 2017-04-12 2755
36eca894832351 Arianna Avanzini 2017-04-12 2756 /*
36eca894832351 Arianna Avanzini 2017-04-12 2757 * If there are no process references on the new_bfqq, then it is
36eca894832351 Arianna Avanzini 2017-04-12 2758 * unsafe to follow the ->new_bfqq chain as other bfqq's in the chain
36eca894832351 Arianna Avanzini 2017-04-12 2759 * may have dropped their last reference (not just their last process
36eca894832351 Arianna Avanzini 2017-04-12 2760 * reference).
36eca894832351 Arianna Avanzini 2017-04-12 2761 */
36eca894832351 Arianna Avanzini 2017-04-12 2762 if (!bfqq_process_refs(new_bfqq))
36eca894832351 Arianna Avanzini 2017-04-12 2763 return NULL;
36eca894832351 Arianna Avanzini 2017-04-12 2764
36eca894832351 Arianna Avanzini 2017-04-12 2765 /* Avoid a circular list and skip interim queue merges. */
114533e1e26a36 Kemeng Shi 2023-02-19 @2766 while ((new_bfqq = new_bfqq->new_bfqq)) {
114533e1e26a36 Kemeng Shi 2023-02-19 2767 if (new_bfqq == bfqq)
36eca894832351 Arianna Avanzini 2017-04-12 2768 return NULL;
36eca894832351 Arianna Avanzini 2017-04-12 2769 }
This now loops until new_bfqq is NULL.
36eca894832351 Arianna Avanzini 2017-04-12 2770
36eca894832351 Arianna Avanzini 2017-04-12 2771 process_refs = bfqq_process_refs(bfqq);
36eca894832351 Arianna Avanzini 2017-04-12 2772 new_process_refs = bfqq_process_refs(new_bfqq);
What?
36eca894832351 Arianna Avanzini 2017-04-12 2773 /*
36eca894832351 Arianna Avanzini 2017-04-12 2774 * If the process for the bfqq has gone away, there is no
36eca894832351 Arianna Avanzini 2017-04-12 2775 * sense in merging the queues.
36eca894832351 Arianna Avanzini 2017-04-12 2776 */
36eca894832351 Arianna Avanzini 2017-04-12 2777 if (process_refs == 0 || new_process_refs == 0)
36eca894832351 Arianna Avanzini 2017-04-12 2778 return NULL;
36eca894832351 Arianna Avanzini 2017-04-12 2779
c1cee4ab36acef Jan Kara 2022-04-01 2780 /*
c1cee4ab36acef Jan Kara 2022-04-01 2781 * Make sure merged queues belong to the same parent. Parents could
c1cee4ab36acef Jan Kara 2022-04-01 2782 * have changed since the time we decided the two queues are suitable
c1cee4ab36acef Jan Kara 2022-04-01 2783 * for merging.
c1cee4ab36acef Jan Kara 2022-04-01 2784 */
c1cee4ab36acef Jan Kara 2022-04-01 @2785 if (new_bfqq->entity.parent != bfqq->entity.parent)
c1cee4ab36acef Jan Kara 2022-04-01 2786 return NULL;
c1cee4ab36acef Jan Kara 2022-04-01 2787
36eca894832351 Arianna Avanzini 2017-04-12 2788 bfq_log_bfqq(bfqq->bfqd, bfqq, "scheduling merge with queue %d",
36eca894832351 Arianna Avanzini 2017-04-12 2789 new_bfqq->pid);
36eca894832351 Arianna Avanzini 2017-04-12 2790
36eca894832351 Arianna Avanzini 2017-04-12 2791 /*
36eca894832351 Arianna Avanzini 2017-04-12 2792 * Merging is just a redirection: the requests of the process
36eca894832351 Arianna Avanzini 2017-04-12 2793 * owning one of the two queues are redirected to the other queue.
36eca894832351 Arianna Avanzini 2017-04-12 2794 * The latter queue, in its turn, is set as shared if this is the
36eca894832351 Arianna Avanzini 2017-04-12 2795 * first time that the requests of some process are redirected to
36eca894832351 Arianna Avanzini 2017-04-12 2796 * it.
36eca894832351 Arianna Avanzini 2017-04-12 2797 *
6fa3e8d34204d5 Paolo Valente 2017-04-12 2798 * We redirect bfqq to new_bfqq and not the opposite, because
6fa3e8d34204d5 Paolo Valente 2017-04-12 2799 * we are in the context of the process owning bfqq, thus we
6fa3e8d34204d5 Paolo Valente 2017-04-12 2800 * have the io_cq of this process. So we can immediately
6fa3e8d34204d5 Paolo Valente 2017-04-12 2801 * configure this io_cq to redirect the requests of the
6fa3e8d34204d5 Paolo Valente 2017-04-12 2802 * process to new_bfqq. In contrast, the io_cq of new_bfqq is
6fa3e8d34204d5 Paolo Valente 2017-04-12 2803 * not available any more (new_bfqq->bic == NULL).
6fa3e8d34204d5 Paolo Valente 2017-04-12 2804 *
6fa3e8d34204d5 Paolo Valente 2017-04-12 2805 * Anyway, even in case new_bfqq coincides with the in-service
6fa3e8d34204d5 Paolo Valente 2017-04-12 2806 * queue, redirecting requests the in-service queue is the
6fa3e8d34204d5 Paolo Valente 2017-04-12 2807 * best option, as we feed the in-service queue with new
6fa3e8d34204d5 Paolo Valente 2017-04-12 2808 * requests close to the last request served and, by doing so,
6fa3e8d34204d5 Paolo Valente 2017-04-12 2809 * are likely to increase the throughput.
36eca894832351 Arianna Avanzini 2017-04-12 2810 */
36eca894832351 Arianna Avanzini 2017-04-12 2811 bfqq->new_bfqq = new_bfqq;
15729ff8143f81 Paolo Valente 2021-11-25 2812 /*
15729ff8143f81 Paolo Valente 2021-11-25 2813 * The above assignment schedules the following redirections:
15729ff8143f81 Paolo Valente 2021-11-25 2814 * each time some I/O for bfqq arrives, the process that
15729ff8143f81 Paolo Valente 2021-11-25 2815 * generated that I/O is disassociated from bfqq and
15729ff8143f81 Paolo Valente 2021-11-25 2816 * associated with new_bfqq. Here we increases new_bfqq->ref
15729ff8143f81 Paolo Valente 2021-11-25 2817 * in advance, adding the number of processes that are
15729ff8143f81 Paolo Valente 2021-11-25 2818 * expected to be associated with new_bfqq as they happen to
15729ff8143f81 Paolo Valente 2021-11-25 2819 * issue I/O.
15729ff8143f81 Paolo Valente 2021-11-25 2820 */
36eca894832351 Arianna Avanzini 2017-04-12 2821 new_bfqq->ref += process_refs;
36eca894832351 Arianna Avanzini 2017-04-12 2822 return new_bfqq;
36eca894832351 Arianna Avanzini 2017-04-12 2823 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
on 2/23/2023 1:48 PM, Dan Carpenter wrote:
> Hi Kemeng,
>
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Kemeng-Shi/block-bfq-properly-mark-bfqq-remained-idle/20230219-104312
> base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next
> patch link: https://lore.kernel.org/r/20230219104309.1511562-18-shikemeng%40huaweicloud.com
> patch subject: [PATCH 17/17] block, bfq: remove unnecessary local variable __bfqq in bfq_setup_merge
> config: openrisc-randconfig-m041-20230219 (https://download.01.org/0day-ci/archive/20230220/[email protected]/config)
> compiler: or1k-linux-gcc (GCC) 12.1.0
>
> If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot <[email protected]>
> | Reported-by: Dan Carpenter <[email protected]>
> | Link: https://lore.kernel.org/r/[email protected]/
>
> New smatch warnings:
> block/bfq-iosched.c:2785 bfq_setup_merge() error: we previously assumed 'new_bfqq' could be null (see line 2766)
>
> Old smatch warnings:
> block/bfq-iosched.c:6195 __bfq_insert_request() warn: variable dereferenced before check 'bfqq' (see line 6191)
>
> vim +/new_bfqq +2785 block/bfq-iosched.c
>
> 36eca894832351 Arianna Avanzini 2017-04-12 2751 static struct bfq_queue *
> 36eca894832351 Arianna Avanzini 2017-04-12 2752 bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq)
> 36eca894832351 Arianna Avanzini 2017-04-12 2753 {
> 36eca894832351 Arianna Avanzini 2017-04-12 2754 int process_refs, new_process_refs;
> 36eca894832351 Arianna Avanzini 2017-04-12 2755
> 36eca894832351 Arianna Avanzini 2017-04-12 2756 /*
> 36eca894832351 Arianna Avanzini 2017-04-12 2757 * If there are no process references on the new_bfqq, then it is
> 36eca894832351 Arianna Avanzini 2017-04-12 2758 * unsafe to follow the ->new_bfqq chain as other bfqq's in the chain
> 36eca894832351 Arianna Avanzini 2017-04-12 2759 * may have dropped their last reference (not just their last process
> 36eca894832351 Arianna Avanzini 2017-04-12 2760 * reference).
> 36eca894832351 Arianna Avanzini 2017-04-12 2761 */
> 36eca894832351 Arianna Avanzini 2017-04-12 2762 if (!bfqq_process_refs(new_bfqq))
> 36eca894832351 Arianna Avanzini 2017-04-12 2763 return NULL;
> 36eca894832351 Arianna Avanzini 2017-04-12 2764
> 36eca894832351 Arianna Avanzini 2017-04-12 2765 /* Avoid a circular list and skip interim queue merges. */
> 114533e1e26a36 Kemeng Shi 2023-02-19 @2766 while ((new_bfqq = new_bfqq->new_bfqq)) {
> 114533e1e26a36 Kemeng Shi 2023-02-19 2767 if (new_bfqq == bfqq)
> 36eca894832351 Arianna Avanzini 2017-04-12 2768 return NULL;
> 36eca894832351 Arianna Avanzini 2017-04-12 2769 }
>
> This now loops until new_bfqq is NULL.
>
> 36eca894832351 Arianna Avanzini 2017-04-12 2770
> 36eca894832351 Arianna Avanzini 2017-04-12 2771 process_refs = bfqq_process_refs(bfqq);
> 36eca894832351 Arianna Avanzini 2017-04-12 2772 new_process_refs = bfqq_process_refs(new_bfqq);
>
> What?Sorry, I didn't expect that there is a behavior change. I will drop
this one in next version. Thanks.
--
Best wishes
Kemeng Shi
Greeting,
FYI, we noticed maybe_for_address#:#[##] due to commit (built with gcc-11):
commit: 114533e1e26a36efa829659b34941a78b158b613 ("[PATCH 17/17] block, bfq: remove unnecessary local variable __bfqq in bfq_setup_merge")
url: https://github.com/intel-lab-lkp/linux/commits/Kemeng-Shi/block-bfq-properly-mark-bfqq-remained-idle/20230219-104312
base: https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git for-next
patch link: https://lore.kernel.org/all/[email protected]/
patch subject: [PATCH 17/17] block, bfq: remove unnecessary local variable __bfqq in bfq_setup_merge
in testcase: blktests
version: blktests-x86_64-f28eb90-1_20230214
with following parameters:
disk: 1SSD
test: block-group-07
on test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
| Reported-by: kernel test robot <[email protected]>
| Link: https://lore.kernel.org/oe-lkp/[email protected]
[ 96.679266][ T1230] general protection fault, maybe for address 0x7: 0000 [#1] SMP KASAN PTI
[ 96.687702][ T1230] CPU: 3 PID: 1230 Comm: dd Not tainted 6.2.0-rc7-00473-g114533e1e26a #1
[ 96.695955][ T1230] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.8.1 12/05/2017
[ 96.704033][ T1230] RIP: 0010:bfq_setup_merge+0x210/0x460
[ 96.709428][ T1230] Code: 00 00 00 fc ff df 48 89 fa 41 0f 95 c5 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 01 00 00 <a0> 00 00 00 00 00 fc ff df 44 03 65 04 44 29 e3 44 29 f3 44 29 eb
[ 96.728893][ T1230] RSP: 0018:ffffc900028ef5a0 EFLAGS: 00010046
[ 96.734815][ T1230] RAX: 0000000000000007 RBX: 0000000000000001 RCX: 00000000fffcd90b
[ 96.742646][ T1230] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88880532cb04
[ 96.750463][ T1230] RBP: ffff88880532cb00 R08: 1ffff11100f59f7f R09: ffff888802356093
[ 96.758284][ T1230] R10: ffffed110046ac12 R11: 0000000000000001 R12: 0000000000000000
[ 96.766100][ T1230] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 96.773919][ T1230] FS: 00007f6ad3490580(0000) GS:ffff888791780000(0000) knlGS:0000000000000000
[ 96.782694][ T1230] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 96.789124][ T1230] CR2: 000055822213cd38 CR3: 000000025d70c002 CR4: 00000000003706e0
[ 96.796943][ T1230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 96.804762][ T1230] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 96.812583][ T1230] Call Trace:
[ 96.815720][ T1230] <TASK>
[ 96.818511][ T1230] bfq_get_queue+0x736/0xb40
[ 96.822953][ T1230] bfq_get_bfqq_handle_split+0x124/0x5c0
[ 96.828434][ T1230] bfq_init_rq+0x301/0x1780
[ 96.832789][ T1230] ? radix_tree_node_alloc+0x183/0x2c0
[ 96.839138][ T1230] ? elv_merge+0x144/0x3c0
[ 96.843405][ T1230] ? __bfq_insert_request+0x1850/0x1850
[ 96.849406][ T1230] ? _raw_spin_lock_irq+0x86/0xe0
[ 96.854279][ T1230] ? _raw_spin_lock_bh+0xe0/0xe0
[ 96.859065][ T1230] bfq_insert_request+0xdd/0x700
[ 96.864458][ T1230] ? bfq_init_rq+0x1780/0x1780
[ 96.869070][ T1230] ? ioc_find_get_icq+0x195/0x220
[ 96.873944][ T1230] bfq_insert_requests+0x12e/0x220
[ 96.878903][ T1230] ? blk_mq_get_new_requests+0x28e/0x500
[ 96.884381][ T1230] blk_mq_sched_insert_request+0x26d/0x450
[ 96.890035][ T1230] ? blk_mq_sched_bio_merge+0x390/0x390
[ 96.895430][ T1230] ? internal_get_user_pages_fast+0xfa/0x210
[ 96.901257][ T1230] blk_mq_submit_bio+0xb28/0x11d0
[ 96.906132][ T1230] ? copy_page_from_iter_atomic+0x1140/0x1140
[ 96.912045][ T1230] ? blk_mq_try_issue_list_directly+0x310/0x310
[ 96.918129][ T1230] ? find_next_iomem_res+0x239/0x470
[ 96.923261][ T1230] submit_bio_noacct_nocheck+0x481/0x630
[ 96.928739][ T1230] ? should_fail_request+0x70/0x70
[ 96.933701][ T1230] ? __cond_resched+0x20/0x90
[ 96.938226][ T1230] ? bio_add_zone_append_page+0x2b0/0x2b0
[ 96.943794][ T1230] ? get_page_from_freelist+0x6a4/0xc60
[ 96.949187][ T1230] submit_bio_wait+0xfb/0x1f0
[ 96.953714][ T1230] ? __bio_clone+0x300/0x300
[ 96.958163][ T1230] ? bio_iov_iter_get_pages+0xa2/0x250
[ 96.963476][ T1230] ? bio_init+0x31b/0x580
[ 96.967663][ T1230] __blkdev_direct_IO_simple+0x3ef/0x710
[ 96.973149][ T1230] ? __blkdev_direct_IO_async+0x6f0/0x6f0
[ 96.978727][ T1230] ? current_time+0x77/0x220
[ 96.983171][ T1230] ? mode_strip_sgid+0x170/0x170
[ 96.987956][ T1230] ? submit_bio_wait+0x1f0/0x1f0
[ 96.992742][ T1230] ? folio_add_lru_vma+0x74/0xa0
[ 96.997530][ T1230] blkdev_read_iter+0x1f9/0x550
[ 97.002230][ T1230] vfs_read+0x577/0x800
[ 97.006237][ T1230] ? kernel_read+0x130/0x130
[ 97.010679][ T1230] ? __fget_light+0x51/0x220
[ 97.015120][ T1230] ksys_read+0xf1/0x1c0
[ 97.019124][ T1230] ? __ia32_sys_pwrite64+0x1e0/0x1e0
[ 97.024258][ T1230] ? fput+0x1d/0x130
[ 97.028004][ T1230] do_syscall_64+0x39/0x80
[ 97.032271][ T1230] entry_SYSCALL_64_after_hwframe+0x5e/0xc8
[ 97.038013][ T1230] RIP: 0033:0x7f6ad33a678e
[ 97.042279][ T1230] Code: c0 e9 b6 fe ff ff 50 48 8d 3d ee 04 0b 00 e8 a9 fd 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28
[ 97.061718][ T1230] RSP: 002b:00007ffd930cfb08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 97.069974][ T1230] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007f6ad33a678e
[ 97.077794][ T1230] RDX: 0000000000001000 RSI: 000055822213a000 RDI: 0000000000000000
[ 97.085616][ T1230] RBP: 000055822213a000 R08: 0000558222139d30 R09: 00007f6ad3489be0
[ 97.093436][ T1230] R10: ffffffffffffff3f R11: 0000000000000246 R12: 0000000000000000
[ 97.101257][ T1230] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000004
[ 97.109078][ T1230] </TASK>
[ 97.111955][ T1230] Modules linked in: null_blk loop dm_multipath dm_mod btrfs ipmi_devintf ipmi_msghandler blake2b_generic xor raid6_pq zstd_compress libcrc32c intel_rapl_msr intel_rapl_common sd_mod t10_pi x86_pkg_temp_thermal crc64_rocksoft_generic intel_powerclamp crc64_rocksoft coretemp crc64 sg kvm_intel i915 kvm irqbypass drm_buddy crct10dif_pclmul intel_gtt crc32_pclmul crc32c_intel drm_display_helper mei_wdt ghash_clmulni_intel ahci ttm sha512_ssse3 rapl libahci wmi_bmof intel_cstate mei_me drm_kms_helper i2c_i801 syscopyarea intel_uncore mei sysfillrect libata video i2c_smbus intel_pch_thermal sysimgblt wmi intel_pmc_core acpi_pad drm fuse ip_tables [last unloaded: null_blk]
[ 97.172592][ T1230] ---[ end trace 0000000000000000 ]---
[ 97.177897][ T1230] RIP: 0010:bfq_setup_merge+0x210/0x460
[ 97.183291][ T1230] Code: 00 00 00 fc ff df 48 89 fa 41 0f 95 c5 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 01 00 00 <a0> 00 00 00 00 00 fc ff df 44 03 65 04 44 29 e3 44 29 f3 44 29 eb
[ 97.202748][ T1230] RSP: 0018:ffffc900028ef5a0 EFLAGS: 00010046
[ 97.208673][ T1230] RAX: 0000000000000007 RBX: 0000000000000001 RCX: 00000000fffcd90b
[ 97.216507][ T1230] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88880532cb04
[ 97.224335][ T1230] RBP: ffff88880532cb00 R08: 1ffff11100f59f7f R09: ffff888802356093
[ 97.232157][ T1230] R10: ffffed110046ac12 R11: 0000000000000001 R12: 0000000000000000
[ 97.239977][ T1230] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 97.247798][ T1230] FS: 00007f6ad3490580(0000) GS:ffff888791780000(0000) knlGS:0000000000000000
[ 97.256574][ T1230] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 97.263007][ T1230] CR2: 000055822213cd38 CR3: 000000025d70c002 CR4: 00000000003706e0
[ 97.270826][ T1230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 97.278649][ T1230] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 97.286471][ T1230] Kernel panic - not syncing: Fatal exception
[ 98.355008][ T1230] Shutting down cpus with NMI
[ 98.359536][ T1230] Kernel Offset: disabled
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
sudo bin/lkp install job.yaml # job file is attached in this email
bin/lkp split-job --compatible job.yaml # generate the yaml file for lkp run
sudo bin/lkp run generated-yaml-file
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests