From: Lai Jiangshan la...@cn.fujitsu.com
worker destruction includes these parts of code:
adjust pool's stats
remove the worker from idle list
detach the worker from the pool
kthread_stop() to wait for the worker's task exit
free the worker struct
We can
From: Lai Jiangshan la...@cn.fujitsu.com
worker_idr is highly bound to managers and is always/only accessed in manager
lock context. So we don't need pool-lock for it.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
Signed-off-by: Tejun Heo t...@kernel.org
(cherry picked from commit
From: Lai Jiangshan la...@cn.fujitsu.com
We used to have the CPU online failure path where a worker is created
and then destroyed without being started. A worker was created for
the CPU coming online and if the online operation failed the created worker
was shut down without being started. But
From: Lai Jiangshan la...@cn.fujitsu.com
Since destroy_worker() doesn't need to sleep nor require manager_mutex,
destroy_worker() can be directly called in the idle timeout
handler, it helps us remove POOL_MANAGE_WORKERS and
maybe_destroy_worker() and simplify the manage_workers()
After
Hi Bruce,
As we discussed before, these patch series intended to fix a potential
kernel crash, which is due to a invalid mm context from worker_create,
and it is introduced by efb5fea2, which is a continuation of efforts
trying to optimize find_vma(), avoiding potentially expensive rbtree
