From: Yafang Shao <laoar.shao@gmail.com>
To: vincent.guittot@linaro.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com
Cc: linux-kernel@vger.kernel.org, Yafang Shao <laoar.shao@gmail.com>,
Valentin Schneider <valentin.schneider@arm.com>
Subject: [PATCH] sched, fair: try to prevent migration thread from preempting non-cfs task
Date: Tue, 15 Jun 2021 20:15:51 +0800 [thread overview]
Message-ID: <20210615121551.31138-1-laoar.shao@gmail.com> (raw)
We monitored our latency-sensitive RT tasks are randomly preempted by the
kthread migration/n, which means to migrate task from CPUn to the new
idle CPU which wakes up the migration/n. For example,
sensing_node-2511 [007] d... 945.351566: sched_switch: prev_comm=sensing_node prev_pid=2511 prev_prio=98 prev_state=S ==> next_comm=cat next_pid=2686 next_prio=120
cat-2686 [007] d... 945.351569: sched_switch: prev_comm=cat prev_pid=2686 prev_prio=120 prev_state=R+ ==> next_comm=sensing_node next_pid=2512 next_prio=98
sensing_node-2516 [004] dn.. 945.351571: sched_wakeup: comm=migration/7 pid=47 prio=0 target_cpu=007
sensing_node-2512 [007] d... 945.351572: sched_switch: prev_comm=sensing_node prev_pid=2512 prev_prio=98 prev_state=R ==> next_comm=migration/7 next_pid=47 next_prio=0
sensing_node-2516 [004] d... 945.351572: sched_switch: prev_comm=sensing_node prev_pid=2516 prev_prio=98 prev_state=S ==> next_comm=sensing_node next_pid=2502 next_prio=98
migration/7-47 [007] d... 945.351580: sched_switch: prev_comm=migration/7 prev_pid=47 prev_prio=0 prev_state=S ==> next_comm=sensing_node next_pid=2512 next_prio=98
sensing_node-2502 [004] d... 945.351605: sched_switch: prev_comm=sensing_node prev_pid=2502 prev_prio=98 prev_state=S ==> next_comm=cat next_pid=2686 next_prio=120
When CPU4 is waking migration/7, the CFS thread 'cat' is running on
CPU7, but then 'cat' is preempted by a RT task 'sensing_node', and
then the migration/7 preempts the RT task. The race happens between:
if (need_active_balance(&env)) {
and
raw_spin_rq_lock_irqsave(busiest, flags);
In order to reduce the race, we'd better do the last minute check before
waking up migration thread.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
---
- Prev version
https://lore.kernel.org/lkml/CAKfTPtBd349eyDhA5ThCAHFd83cGMQKb_LDxD4QvyP-cJOBjqA@mail.gmail.com/
- Similar discussion
https://lore.kernel.org/lkml/CAKfTPtBygNcVewbb0GQOP5xxO96am3YeTZNP5dK9BxKHJJAL-g@mail.gmail.com/
---
kernel/sched/fair.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3248e24a90b0..597c7a940746 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9797,6 +9797,20 @@ static int load_balance(int this_cpu, struct rq *this_rq,
/* Record that we found at least one task that could run on this_cpu */
env.flags &= ~LBF_ALL_PINNED;
+ /*
+ * There may be a race between load balance starting migration
+ * thread to pull the cfs running thread and the RT thread
+ * waking up and preempting cfs task before migration threads
+ * which then preempt the RT thread.
+ * We'd better do the last minute check before starting
+ * migration thread to avoid preempting latency-sensitive thread.
+ */
+ if (busiest->curr->sched_class != &fair_sched_class) {
+ raw_spin_unlock_irqrestore(&busiest->lock,
+ flags);
+ goto out;
+ }
+
/*
* ->active_balance synchronizes accesses to
* ->active_balance_work. Once set, it's cleared
--
2.17.1
next reply other threads:[~2021-06-15 12:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 12:15 Yafang Shao [this message]
2021-06-15 14:55 ` Valentin Schneider
2021-06-15 15:45 ` Vincent Guittot
2021-06-15 16:39 ` Valentin Schneider
2021-06-15 20:35 ` Peter Zijlstra
2021-06-16 1:44 ` Yafang Shao
2021-06-16 7:15 ` Peter Zijlstra
2021-06-16 7:29 ` Vincent Guittot
2021-06-16 8:29 ` Peter Zijlstra
2021-06-16 9:49 ` Yafang Shao
2021-06-16 9:45 ` Yafang Shao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210615121551.31138-1-laoar.shao@gmail.com \
--to=laoar.shao@gmail.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®