Lines Matching refs:wq
21 is needed and the workqueue (wq) API is the most commonly used
37 In the original wq implementation, a multi threaded (MT) wq had one
38 worker thread per CPU and a single threaded (ST) wq had one worker
39 thread system-wide. A single MT wq needed to keep around the same
41 wq users over the years and with the number of CPU cores continuously
45 Although MT wq wasted a lot of resource, the level of concurrency
47 MT wq albeit less severe on MT. Each wq maintained its own separate
48 worker pool. A MT wq could provide only one execution context per CPU
49 while a ST wq one for the whole system. Work items had to compete for
55 choosing to use ST wq for polling PIOs and accepting an unnecessary
57 MT wq don't provide much better concurrency, users which require
61 Concurrency Managed Workqueue (cmwq) is a reimplementation of wq with
66 * Use per-CPU unified worker pools shared by all wq to provide
142 mark a bound wq to ignore the concurrency management. Please refer to
149 wq's that have a rescue-worker reserved for execution under memory
156 alloc_workqueue() allocates a wq. The original create_*workqueue()
159 name of the wq and also used as the name of the rescuer thread if
162 A wq no longer manages execution resources but serves as a domain for
171 Work items queued to an unbound wq are served by the special
173 specific CPU. This makes the wq behave as a simple execution
176 possible. Unbound wq sacrifices locality but is useful for
180 expected and using bound wq may end up creating large number
189 A freezable wq participates in the freeze phase of the system
190 suspend operations. Work items on the wq are drained and no
195 All wq which might be used in the memory reclaim paths _MUST_
196 have this flag set. The wq is guaranteed to have at least one
201 Work items of a highpri wq are queued to the highpri
211 Work items of a CPU intensive wq do not contribute to the
224 This flag is meaningless for unbound wq.
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
237 Currently, for a bound wq, the maximum limit for @max_active is 512
239 wq, the limit is higher of 512 and 4 * num_possible_cpus(). These
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
249 Some users depend on the strict execution ordering of ST wq. The
251 behavior. Work items on such wq are always queued to the unbound
253 achieving the same ordering property as ST wq.
261 Work items w0, w1, w2 are queued to a bound wq q0 on the same CPU.
268 of possible sequences of events with the original wq.
310 Now, let's assume w1 and w2 are queued to a different wq q1 which has
327 * Do not forget to use WQ_MEM_RECLAIM if a wq may process work items
328 which are used during memory reclaim. Each wq with WQ_MEM_RECLAIM
331 they should be queued to separate wq each with WQ_MEM_RECLAIM.
333 * Unless strict ordering is required, there is no need to use ST wq.
339 * A wq serves as a domain for forward progress guarantee
343 attribute, can use one of the system wq. There is no difference in
344 execution characteristics between using a dedicated wq and a system
345 wq.
348 cycles, using a bound wq is usually beneficial due to the increased
349 level of locality in wq operations and work item execution.