summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/exported-sql-viewer.py
diff options
context:
space:
mode:
authorValentin Schneider <vschneid@redhat.com>2023-01-12 19:14:31 +0300
committerTejun Heo <tj@kernel.org>2023-01-12 19:21:49 +0300
commite02b93124855cd34b78e61ae44846c8cb5fddfc3 (patch)
treebbee233a318cf815b387fa5a95b05ffca0a29de8 /tools/perf/scripts/python/exported-sql-viewer.py
parent9ab03be42b8f9136dcc01a90ecc9ac71bc6149ef (diff)
downloadlinux-e02b93124855cd34b78e61ae44846c8cb5fddfc3.tar.xz
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 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions