Skip to content

Commit e3dddcf

Browse files
Chen Ridonghtejun
authored andcommitted
workqueue: doc: Add a note saturating the system_wq is not permitted
If something is expected to generate large number of concurrent works, it should utilize its own dedicated workqueue rather than system wq. Because this may saturate system_wq and potentially block other's works. eg, cgroup release work. Let's document this as a note. Signed-off-by: Chen Ridong <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
1 parent 9852d85 commit e3dddcf

File tree

1 file changed

+5
-0
lines changed

1 file changed

+5
-0
lines changed

Documentation/core-api/workqueue.rst

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -357,6 +357,11 @@ Guidelines
357357
difference in execution characteristics between using a dedicated wq
358358
and a system wq.
359359

360+
Note: If something may generate more than @max_active outstanding
361+
work items (do stress test your producers), it may saturate a system
362+
wq and potentially lead to deadlock. It should utilize its own
363+
dedicated workqueue rather than the system wq.
364+
360365
* Unless work items are expected to consume a huge amount of CPU
361366
cycles, using a bound wq is usually beneficial due to the increased
362367
level of locality in wq operations and work item execution.

0 commit comments

Comments
 (0)