diff options
| author | Tejun Heo <tj@kernel.org> | 2023-05-18 06:02:08 +0300 |
|---|---|---|
| committer | Tejun Heo <tj@kernel.org> | 2023-05-18 06:02:08 +0300 |
| commit | 6363845005202148b8409ec3082e80845c19d309 (patch) | |
| tree | d834394ee879ef14687a4a0f5cda31f0e5899bec /Documentation/admin-guide | |
| parent | 616db8779b1e3f93075df691432cccc5ef3c3ba0 (diff) | |
| download | linux-6363845005202148b8409ec3082e80845c19d309.tar.xz | |
workqueue: Report work funcs that trigger automatic CPU_INTENSIVE mechanism
Workqueue now automatically marks per-cpu work items that hog CPU for too
long as CPU_INTENSIVE, which excludes them from concurrency management and
prevents stalling other concurrency-managed work items. If a work function
keeps running over the thershold, it likely needs to be switched to use an
unbound workqueue.
This patch adds a debug mechanism which tracks the work functions which
trigger the automatic CPU_INTENSIVE mechanism and report them using
pr_warn() with exponential backoff.
v3: Documentation update.
v2: Drop bouncing to kthread_worker for printing messages. It was to avoid
introducing circular locking dependency through printk but not effective
as it still had pool lock -> wci_lock -> printk -> pool lock loop. Let's
just print directly using printk_deferred().
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Diffstat (limited to 'Documentation/admin-guide')
| -rw-r--r-- | Documentation/admin-guide/kernel-parameters.txt | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1f2185cf2f0a..3ed7dda4c994 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6938,6 +6938,11 @@ them from noticeably delaying other per-cpu work items. Default is 10000 (10ms). + If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel + will report the work functions which violate this + threshold repeatedly. They are likely good + candidates for using WQ_UNBOUND workqueues instead. + workqueue.disable_numa By default, all work items queued to unbound workqueues are affine to the NUMA nodes they're |