linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@kernel.org, peterz@infradead.org,
	vincent.guittot@linaro.org, tglx@linutronix.de,
	qais.yousef@arm.com
Subject: [PATCH v2 4/4] sched/fair: Prevent active LB from preempting higher sched classes
Date: Thu, 15 Aug 2019 15:51:07 +0100	[thread overview]
Message-ID: <20190815145107.5318-5-valentin.schneider@arm.com> (raw)
In-Reply-To: <20190815145107.5318-1-valentin.schneider@arm.com>

The CFS load balancer can cause the cpu_stopper to run a function to
try and steal a remote rq's running task. However, it so happens
that while only CFS tasks will ever be migrated by that function, we
can end up preempting higher sched class tasks, since it is executed
by the cpu_stopper.

This can potentially occur whenever a rq's running task is > CFS but
the rq has runnable CFS tasks.

Check the sched class of the remote rq's running task after we've
grabbed its lock. If it's CFS, carry on, otherwise run
detach_one_task() locally since we don't need the cpu_stopper (that
!CFS task is doing the exact same thing).

Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
---
 kernel/sched/fair.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8f5f6cad5008..bf4f7f43252f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8759,6 +8759,7 @@ static inline enum alb_status active_load_balance(struct lb_env *env)
 	enum alb_status status = cancelled;
 	struct sched_domain *sd = env->sd;
 	struct rq *busiest = env->src_rq;
+	struct task_struct *p = NULL;
 	unsigned long flags;
 
 	schedstat_inc(sd->lb_failed[env->idle]);
@@ -8780,6 +8781,16 @@ static inline enum alb_status active_load_balance(struct lb_env *env)
 	if (busiest->cfs.h_nr_running < 1)
 		goto unlock;
 
+	/*
+	 * If busiest->curr isn't CFS, then there's no point in running the
+	 * cpu_stopper. We can try to nab one CFS task though, since they're
+	 * all ready to be plucked.
+	 */
+	if (busiest->curr->sched_class != &fair_sched_class) {
+		p = detach_one_task(env);
+		goto unlock;
+	}
+
 	/*
 	 * Don't kick the active_load_balance_cpu_stop, if the curr task on
 	 * busiest CPU can't be moved to dst_cpu:
@@ -8803,7 +8814,9 @@ static inline enum alb_status active_load_balance(struct lb_env *env)
 unlock:
 	raw_spin_unlock_irqrestore(&busiest->lock, flags);
 
-	if (status == started)
+	if (p)
+		attach_one_task(env->dst_rq, p);
+	else if (status == started)
 		stop_one_cpu_nowait(cpu_of(busiest),
 				    active_load_balance_cpu_stop, busiest,
 				    &busiest->active_balance_work);
-- 
2.22.0


  parent reply	other threads:[~2019-08-15 14:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 14:51 [PATCH v2 0/4] sched/fair: Active balancer RT/DL preemption fix Valentin Schneider
2019-08-15 14:51 ` [PATCH v2 1/4] sched/fair: Make need_active_balance() return bools Valentin Schneider
2019-08-15 14:51 ` [PATCH v2 2/4] sched/fair: Move active balance logic to its own function Valentin Schneider
2019-10-01 11:36   ` Srikar Dronamraju
2019-10-01 11:48     ` Valentin Schneider
2019-08-15 14:51 ` [PATCH v2 3/4] sched/fair: Check for CFS tasks before detach_one_task() Valentin Schneider
2019-08-15 14:51 ` Valentin Schneider [this message]
2019-08-27 12:28   ` [PATCH v2 4/4] sched/fair: Prevent active LB from preempting higher sched classes Vincent Guittot
2019-08-28  9:46     ` Valentin Schneider
2019-08-29 14:19       ` Vincent Guittot
2019-08-30 15:44         ` Valentin Schneider
2019-10-01 10:29 ` [PATCH v2 0/4] sched/fair: Active balancer RT/DL preemption fix Valentin Schneider
2019-10-01 13:31   ` Juri Lelli
2019-10-01 14:15     ` Valentin Schneider

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=20190815145107.5318-5-valentin.schneider@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).