diff options
author | Tejun Heo <tj@kernel.org> | 2017-06-17 08:10:08 -0400 |
---|---|---|
committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | 2017-07-28 13:49:53 -0700 |
commit | 955dbdf4ce87fd9be4bc8378e26b8c2eb8b3d184 (patch) | |
tree | 93318ed623afbe3cb7433ec5b89d248e6f1ed143 /tools/laptop | |
parent | 4e3274705324c695f56b3e1c194cd99b76eeea0f (diff) | |
download | linux-stable-955dbdf4ce87fd9be4bc8378e26b8c2eb8b3d184.tar.gz linux-stable-955dbdf4ce87fd9be4bc8378e26b8c2eb8b3d184.tar.bz2 linux-stable-955dbdf4ce87fd9be4bc8378e26b8c2eb8b3d184.zip |
sched: Allow migrating kthreads into online but inactive CPUs
Per-cpu workqueues have been tripping CPU affinity sanity checks while
a CPU is being offlined. A per-cpu kworker ends up running on a CPU
which isn't its target CPU while the CPU is online but inactive.
While the scheduler allows kthreads to wake up on an online but
inactive CPU, it doesn't allow a running kthread to be migrated to
such a CPU, which leads to an odd situation where setting affinity on
a sleeping and running kthread leads to different results.
Each mem-reclaim workqueue has one rescuer which guarantees forward
progress and the rescuer needs to bind itself to the CPU which needs
help in making forward progress; however, due to the above issue,
while set_cpus_allowed_ptr() succeeds, the rescuer doesn't end up on
the correct CPU if the CPU is in the process of going offline,
tripping the sanity check and executing the work item on the wrong
CPU.
This patch updates __migrate_task() so that kthreads can be migrated
into an inactive but online CPU.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Diffstat (limited to 'tools/laptop')
0 files changed, 0 insertions, 0 deletions