| 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: <1431442004-18716-1-git-send-email-xlpang@126.com>
Date: Tue, 12 May 2015 22:46:41 +0800
From: Xunlei Pang <xlpang@....com>
To: linux-kernel@...r.kernel.org
Cc: Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Juri Lelli <juri.lelli@...il.com>,
Ingo Molnar <mingo@...hat.com>,
Xunlei Pang <pang.xunlei@...aro.org>
Subject: [PATCH v3 1/4] sched/rt: Check to push the task away after its affinity was changed
From: Xunlei Pang <pang.xunlei@...aro.org>
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler does nothing about this.
For example: a 2-cpu system with two runnable FIFO tasks(same
rt_priority) bound on CPU0, let's name them rt1(running) and
rt2(runnable) respectively; CPU1 has no RTs. Then, someone sets
the affinity of rt2 to 0x3(i.e. CPU0 and CPU1), but after this,
rt2 still can't be scheduled enters schedule(), this
definitely causes some/big response latency for rt2.
This patch modified set_cpus_allowed_rt(), if the target task
is runnable but not running, it tries to push it away once it
got migratable.
The patch also solves a problem about move_queued_task() called
in set_cpus_allowed_ptr():
When a lower priorioty rt task got migrated due to its curr cpu
isn't in the new affinity mask, after move_queued_task() it will
miss the chance of pushing away, because check_preempt_curr()
called by move_queued_task() doens't set the "need resched flag"
for lower priority tasks.
Signed-off-by: Xunlei Pang <pang.xunlei@...aro.org>
---
kernel/sched/core.c | 10 +++++++---
kernel/sched/deadline.c | 8 +++++---
kernel/sched/rt.c | 29 ++++++++++++++++++++++-------
kernel/sched/sched.h | 3 ++-
4 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d13fc13..c995a02 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4768,11 +4768,15 @@ static struct rq *move_queued_task(struct task_struct *p, int new_cpu)
void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask)
{
+ bool updated = false;
+
if (p->sched_class->set_cpus_allowed)
- p->sched_class->set_cpus_allowed(p, new_mask);
+ updated = p->sched_class->set_cpus_allowed(p, new_mask);
- cpumask_copy(&p->cpus_allowed, new_mask);
- p->nr_cpus_allowed = cpumask_weight(new_mask);
+ if (!updated) {
+ cpumask_copy(&p->cpus_allowed, new_mask);
+ p->nr_cpus_allowed = cpumask_weight(new_mask);
+ }
}
/*
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 5e95145..3baffb2 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1574,7 +1574,7 @@ static void task_woken_dl(struct rq *rq, struct task_struct *p)
}
}
-static void set_cpus_allowed_dl(struct task_struct *p,
+static bool set_cpus_allowed_dl(struct task_struct *p,
const struct cpumask *new_mask)
{
struct rq *rq;
@@ -1610,7 +1610,7 @@ static void set_cpus_allowed_dl(struct task_struct *p,
* it is on the rq AND it is not throttled).
*/
if (!on_dl_rq(&p->dl))
- return;
+ return false;
weight = cpumask_weight(new_mask);
@@ -1619,7 +1619,7 @@ static void set_cpus_allowed_dl(struct task_struct *p,
* can migrate or not.
*/
if ((p->nr_cpus_allowed > 1) == (weight > 1))
- return;
+ return false;
/*
* The process used to be able to migrate OR it can now migrate
@@ -1636,6 +1636,8 @@ static void set_cpus_allowed_dl(struct task_struct *p,
}
update_dl_migration(&rq->dl);
+
+ return false;
}
/* Assumes rq->lock is held */
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 8885b65..4a49c6a 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2241,7 +2241,7 @@ static void task_woken_rt(struct rq *rq, struct task_struct *p)
push_rt_tasks(rq);
}
-static void set_cpus_allowed_rt(struct task_struct *p,
+static bool set_cpus_allowed_rt(struct task_struct *p,
const struct cpumask *new_mask)
{
struct rq *rq;
@@ -2250,18 +2250,19 @@ static void set_cpus_allowed_rt(struct task_struct *p,
BUG_ON(!rt_task(p));
if (!task_on_rq_queued(p))
- return;
+ return false;
weight = cpumask_weight(new_mask);
+ rq = task_rq(p);
+
/*
- * Only update if the process changes its state from whether it
- * can migrate or not.
+ * Skip updating the migration stuff if the process doesn't change
+ * its migrate state, but still need to check if it can be pushed
+ * away due to its new affinity.
*/
if ((p->nr_cpus_allowed > 1) == (weight > 1))
- return;
-
- rq = task_rq(p);
+ goto check_push;
/*
* The process used to be able to migrate OR it can now migrate
@@ -2278,6 +2279,20 @@ static void set_cpus_allowed_rt(struct task_struct *p,
}
update_rt_migration(&rq->rt);
+
+check_push:
+ if (weight > 1 &&
+ !task_running(rq, p) &&
+ !test_tsk_need_resched(rq->curr) &&
+ !cpumask_subset(new_mask, &p->cpus_allowed)) {
+ /* Update new affinity and try to push. */
+ cpumask_copy(&p->cpus_allowed, new_mask);
+ p->nr_cpus_allowed = weight;
+ push_rt_tasks(rq);
+ return true;
+ }
+
+ return false;
}
/* Assumes rq->lock is held */
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e0e1299..101b359 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1189,7 +1189,8 @@ struct sched_class {
void (*task_waking) (struct task_struct *task);
void (*task_woken) (struct rq *this_rq, struct task_struct *task);
- void (*set_cpus_allowed)(struct task_struct *p,
+ /* Return true if p's affinity was updated, false otherwise. */
+ bool (*set_cpus_allowed)(struct task_struct *p,
const struct cpumask *newmask);
void (*rq_online)(struct rq *rq);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists