diff options
| author | Chen Ridong <chenridong@huawei.com> | 2024-10-08 11:24:57 +0000 |
|---|---|---|
| committer | Tejun Heo <tj@kernel.org> | 2024-10-08 08:46:42 -1000 |
| commit | e3dddcfd3dd8b483c9ccaa06733688bb63bb7c9d (patch) | |
| tree | 72f8318603b6f7a4ad99cfbe9413678145156d92 | |
| parent | 9852d85ec9d492ebef56dc5f229416c925758edc (diff) | |
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 <chenridong@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
| -rw-r--r-- | Documentation/core-api/workqueue.rst | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index 16f861c9791e..2b813f80ce39 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -357,6 +357,11 @@ Guidelines difference in execution characteristics between using a dedicated wq and a system wq. + Note: If something may generate more than @max_active outstanding + work items (do stress test your producers), it may saturate a system + wq and potentially lead to deadlock. It should utilize its own + dedicated workqueue rather than the system wq. + * Unless work items are expected to consume a huge amount of CPU cycles, using a bound wq is usually beneficial due to the increased level of locality in wq operations and work item execution. |