[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221003214501.2050087-9-connoro@google.com>
Date: Mon, 3 Oct 2022 21:44:58 +0000
From: "Connor O'Brien" <connoro@...gle.com>
To: linux-kernel@...r.kernel.org
Cc: kernel-team@...roid.com, John Stultz <jstultz@...gle.com>,
Joel Fernandes <joelaf@...gle.com>,
Qais Yousef <qais.yousef@....com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Valentin Schneider <vschneid@...hat.com>,
Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Boqun Feng <boqun.feng@...il.com>,
"Paul E . McKenney" <paulmck@...nel.org>,
"Connor O'Brien" <connoro@...gle.com>
Subject: [RFC PATCH 08/11] sched: Fixup task CPUs for potential proxies.
From: Juri Lelli <juri.lelli@...hat.com>
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@...hat.com>
[Fixed trivial rebase conflict]
Signed-off-by: Valentin Schneider <valentin.schneider@....com>
[fix conflicts]
Signed-off-by: Connor O'Brien <connoro@...gle.com>
---
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
Powered by blists - more mailing lists