diff options
author | Valentin Schneider <vschneid@redhat.com> | 2023-01-12 16:14:31 +0000 |
---|---|---|
committer | Tejun Heo <tj@kernel.org> | 2023-01-12 06:21:49 -1000 |
commit | e02b93124855cd34b78e61ae44846c8cb5fddfc3 (patch) | |
tree | bbee233a318cf815b387fa5a95b05ffca0a29de8 /scripts/gdb/linux/mm.py | |
parent | 9ab03be42b8f9136dcc01a90ecc9ac71bc6149ef (diff) |
workqueue: Unbind kworkers before sending them to exit()
It has been reported that isolated CPUs can suffer from interference due to
per-CPU kworkers waking up just to die.
A surge of workqueue activity during initial setup of a latency-sensitive
application (refresh_vm_stats() being one of the culprits) can cause extra
per-CPU kworkers to be spawned. Then, said latency-sensitive task can be
running merrily on an isolated CPU only to be interrupted sometime later by
a kworker marked for death (cf. IDLE_WORKER_TIMEOUT, 5 minutes after last
kworker activity).
Prevent this by affining kworkers to the wq_unbound_cpumask (which doesn't
contain isolated CPUs, cf. HK_TYPE_WQ) before waking them up after marking
them with WORKER_DIE.
Changing the affinity does require a sleepable context, leverage the newly
introduced pool->idle_cull_work to get that.
Remove dying workers from pool->workers and keep track of them in a
separate list. This intentionally prevents for_each_loop_worker() from
iterating over workers that are marked for death.
Rename destroy_worker() to set_working_dying() to better reflect its
effects and relationship with wake_dying_workers().
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/mm.py')
0 files changed, 0 insertions, 0 deletions