[RFC PATCH 08/11] sched: Fixup task CPUs for potential proxies.
From: Connor O'Brien
Date: Mon Oct 03 2022 - 17:46:09 EST
From: Juri Lelli <juri.lelli@xxxxxxxxxx>
When a mutex owner with potential proxies wakes up those proxies are
activated as well, on the same CPU of the owner. They might have been
sleeping on a different CPU however.
Fixup potential proxies CPU at wakeup time before activating them (or
they get woken up with a wrong CPU reference).
XXX connoro: plan is to fold this into "sched: Add proxy execution" in
future versions.
Signed-off-by: Juri Lelli <juri.lelli@xxxxxxxxxx>
[Fixed trivial rebase conflict]
Signed-off-by: Valentin Schneider <valentin.schneider@xxxxxxx>
[fix conflicts]
Signed-off-by: Connor O'Brien <connoro@xxxxxxxxxx>
---
kernel/sched/core.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 416e61182c17..ad2e7b49f98e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3733,8 +3733,15 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags,
raw_spin_unlock(&pp->blocked_lock);
break;
}
+ /* XXX can't call set_task_cpu() because we are not holding
+ * neither pp->pi_lock nor task's rq lock. This should however
+ * be fine as this task can't be woken up as it is blocked on
+ * this mutex atm.
+ * A problem however might be that __set_task_cpu() calls
+ * set_task_rq() which deals with groups and such...
+ */
+ __set_task_cpu(pp, cpu_of(rq));
activate_task(rq, pp, en_flags);
- pp->on_rq = TASK_ON_RQ_QUEUED;
resched_curr(rq);
raw_spin_unlock(&pp->blocked_lock);
}
@@ -7114,7 +7121,8 @@ static inline void sched_submit_work(struct task_struct *tsk)
* If a worker goes to sleep, notify and ask workqueue whether it
* wants to wake up a task to maintain concurrency.
*/
- if (task_flags & (PF_WQ_WORKER | PF_IO_WORKER)) {
+ if ((task_flags & (PF_WQ_WORKER | PF_IO_WORKER)) &&
+ !task_is_blocked(tsk)) {
if (task_flags & PF_WQ_WORKER)
wq_worker_sleeping(tsk);
else
--
2.38.0.rc1.362.ged0d419d3c-goog