Documentation/core-api/workqueue.rst

22 While there are work items on the workqueue the worker executes the
23 functions associated with the work items one after the other.  When
43 while an ST wq one for the whole system.  Work items had to compete for
88 subsystems and drivers queue work items on and the backend mechanism
89 which manages worker-pools and processes the queued work items.
91 There are two worker-pools, one for normal work items and the other
93 worker-pools to serve work items queued on unbound workqueues - the
102 Subsystems and drivers can create and queue work items through special
104 aspects of the way the work items are executed by setting flags on the
126 number of the currently runnable workers.  Generally, work items are
133 are pending work items.  This allows using a minimal number of workers
150 through the use of rescue workers.  All work items which might be used
168 and ``@max_active`` control how work items are assigned execution
177   workqueues are always per-CPU and all BH work items are executed in the
183   BH work items cannot sleep. All other features such as delayed queueing,
187   Work items queued to an unbound wq are served by the special
191   worker-pools try to start execution of work items as soon as
205   suspend operations.  Work items on the wq are drained and no
214   Work items of a highpri wq are queued to the highpri
223   Work items of a CPU intensive wq do not contribute to the
225   work items will not prevent other work items in the same
227   work items which are expected to hog CPU cycles so that their
230   Although CPU intensive work items don't contribute to the
233   non-CPU-intensive work items can delay execution of CPU
234   intensive work items.
243 CPU which can be assigned to the work items of a wq. For example, with
244 ``@max_active`` of 16, at most 16 work items of the wq can be executing
253 The number of active work items of a wq is usually regulated by the
254 users of the wq, more specifically, by how many work items the users
256 throttling the number of active work items, specifying '0' is
260 is in flight at any given time and the work items are processed in
272  Work items w0, w1, w2 are queued to a bound wq q0 on the same CPU.
340   items which are used during memory reclaim.  Each wq with
342   there is dependency among multiple work items used during memory
353   (``WQ_MEM_RECLAIM``, flush and work item attributes.  Work items
355   flushed as a part of a group of work items, and don't require any
360 * Unless work items are expected to consume a huge amount of CPU
443 cause lower overall system utilization if the work items are not spread