Lines Matching refs:work
24 When such an asynchronous execution context is needed, a work item
29 While there are work items on the workqueue the worker executes the
30 functions associated with the work items one after the other. When
31 there is no work item left on the workqueue the worker becomes idle.
32 When a new work item gets queued, the worker begins executing again.
77 abstraction, the work item, is introduced.
79 A work item is a simple struct that holds a pointer to the function
81 wants a function to be executed asynchronously it has to set up a work
82 item pointing to that function and queue that work item on a
86 off of the queue, one after the other. If no work is queued, the
91 subsystems and drivers queue work items on and the backend mechanism
92 which manages worker-pools and processes the queued work items.
94 There are two worker-pools, one for normal work items and the other
96 worker-pools to serve work items queued on unbound workqueues - the
99 Subsystems and drivers can create and queue work items through special
101 aspects of the way the work items are executed by setting flags on the
102 workqueue they are putting the work item on. These flags include
107 When a work item is queued to a workqueue, the target worker-pool is
110 unless specifically overridden, a work item of a bound workqueue will
123 number of the currently runnable workers. Generally, work items are
125 maintaining just enough concurrency to prevent work processing from
128 work, but, when the last running worker goes to sleep, it immediately
130 are pending work items. This allows using a minimal number of workers
147 through the use of rescue workers. All work items which might be used
163 forward progress guarantee, flush and work item attributes. @flags
164 and @max_active control how work items are assigned execution
175 worker-pools try to start execution of work items as soon as
191 new work item starts execution until thawed.
213 work items will not prevent other work items in the same
215 work items which are expected to hog CPU cycles so that their
218 Although CPU intensive work items don't contribute to the
221 non-CPU-intensive work items can delay execution of CPU
222 intensive work items.
227 are now non-reentrant - any work item is guaranteed to be executed by
233 CPU which can be assigned to the work items of a wq. For example,
234 with @max_active of 16, at most 16 work items of the wq can be
243 The number of active work items of a wq is usually regulated by the
244 users of the wq, more specifically, by how many work items the users
246 throttling the number of active work items, specifying '0' is
252 worker-pools and only one work item can be active at any given time thus
327 * Do not forget to use WQ_MEM_RECLAIM if a wq may process work items
330 dependency among multiple work items used during memory reclaim,
340 (WQ_MEM_RECLAIM, flush and work item attributes. Work items which
342 part of a group of work items, and don't require any special
347 * Unless work items are expected to consume a huge amount of CPU
349 level of locality in wq operations and work item execution.
354 Because the work functions are executed by generic worker threads
369 2. A single work item that consumes lots of cpu cycles
378 If something is busy looping on work queueing, it would be dominating
379 the output and the offender can be determined with the work item
387 The work item's function should be trivially visible in the stack