Skip to content

Commit 636b927

Browse files
committed
workqueue: Make unbound workqueues to use per-cpu pool_workqueues
A pwq (pool_workqueue) represents an association between a workqueue and a worker_pool. When a work item is queued, the workqueue selects the pwq to use, which in turn determines the pool, and queues the work item to the pool through the pwq. pwq is also what implements the maximum concurrency limit - @max_active. As a per-cpu workqueue should be assocaited with a different worker_pool on each CPU, it always had per-cpu pwq's that are accessed through wq->cpu_pwq. However, unbound workqueues were sharing a pwq within each NUMA node by default. The sharing has several downsides: * Because @max_active is per-pwq, the meaning of @max_active changes depending on the machine configuration and whether workqueue NUMA locality support is enabled. * Makes per-cpu and unbound code deviate. * Gets in the way of making workqueue CPU locality awareness more flexible. This patch makes unbound workqueues use per-cpu pwq's the same way per-cpu workqueues do by making the following changes: * wq->numa_pwq_tbl[] is removed and unbound workqueues now use wq->cpu_pwq just like per-cpu workqueues. wq->cpu_pwq is now RCU protected for unbound workqueues. * numa_pwq_tbl_install() is renamed to install_unbound_pwq() and installs the specified pwq to the target CPU's wq->cpu_pwq. * apply_wqattrs_prepare() now always allocates a separate pwq for each CPU unless the workqueue is ordered. If ordered, all CPUs use wq->dfl_pwq. This makes the return value of wq_calc_node_cpumask() unnecessary. It now returns void. * @max_active now means the same thing for both per-cpu and unbound workqueues. WQ_UNBOUND_MAX_ACTIVE now equals WQ_MAX_ACTIVE and documentation is updated accordingly. WQ_UNBOUND_MAX_ACTIVE is no longer used in workqueue implementation and will be removed later. * All unbound pwq operations which used to be per-numa-node are now per-cpu. For most unbound workqueue users, this shouldn't cause noticeable changes. Work item issue and completion will be a small bit faster, flush_workqueue() would become a bit more expensive, and the total concurrency limit would likely become higher. All @max_active==1 use cases are currently being audited for conversion into alloc_ordered_workqueue() and they shouldn't be affected once the audit and conversion is complete. One area where the behavior change may be more noticeable is workqueue_congested() as the reported congestion state is now per CPU instead of NUMA node. There are only two users of this interface - drivers/infiniband/hw/hfi1 and net/smc. Maintainers of both subsystems are cc'd. Inputs on the behavior change would be very much appreciated. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Dennis Dalessandro <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Leon Romanovsky <[email protected]> Cc: Karsten Graul <[email protected]> Cc: Wenjia Zhang <[email protected]> Cc: Jan Karcher <[email protected]>
1 parent 4cbfd3d commit 636b927

File tree

3 files changed

+89
-158
lines changed

3 files changed

+89
-158
lines changed

Documentation/core-api/workqueue.rst

Lines changed: 10 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -220,17 +220,16 @@ resources, scheduled and executed.
220220
``max_active``
221221
--------------
222222

223-
``@max_active`` determines the maximum number of execution contexts
224-
per CPU which can be assigned to the work items of a wq. For example,
225-
with ``@max_active`` of 16, at most 16 work items of the wq can be
226-
executing at the same time per CPU.
227-
228-
Currently, for a bound wq, the maximum limit for ``@max_active`` is
229-
512 and the default value used when 0 is specified is 256. For an
230-
unbound wq, the limit is higher of 512 and 4 *
231-
``num_possible_cpus()``. These values are chosen sufficiently high
232-
such that they are not the limiting factor while providing protection
233-
in runaway cases.
223+
``@max_active`` determines the maximum number of execution contexts per
224+
CPU which can be assigned to the work items of a wq. For example, with
225+
``@max_active`` of 16, at most 16 work items of the wq can be executing
226+
at the same time per CPU. This is always a per-CPU attribute, even for
227+
unbound workqueues.
228+
229+
The maximum limit for ``@max_active`` is 512 and the default value used
230+
when 0 is specified is 256. These values are chosen sufficiently high
231+
such that they are not the limiting factor while providing protection in
232+
runaway cases.
234233

235234
The number of active work items of a wq is usually regulated by the
236235
users of the wq, more specifically, by how many work items the users

include/linux/workqueue.h

Lines changed: 2 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -343,14 +343,10 @@ enum {
343343
__WQ_ORDERED_EXPLICIT = 1 << 19, /* internal: alloc_ordered_workqueue() */
344344

345345
WQ_MAX_ACTIVE = 512, /* I like 512, better ideas? */
346-
WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
346+
WQ_UNBOUND_MAX_ACTIVE = WQ_MAX_ACTIVE,
347347
WQ_DFL_ACTIVE = WQ_MAX_ACTIVE / 2,
348348
};
349349

350-
/* unbound wq's aren't per-cpu, scale max_active according to #cpus */
351-
#define WQ_UNBOUND_MAX_ACTIVE \
352-
max_t(int, WQ_MAX_ACTIVE, num_possible_cpus() * WQ_MAX_UNBOUND_PER_CPU)
353-
354350
/*
355351
* System-wide workqueues which are always present.
356352
*
@@ -391,7 +387,7 @@ extern struct workqueue_struct *system_freezable_power_efficient_wq;
391387
* alloc_workqueue - allocate a workqueue
392388
* @fmt: printf format for the name of the workqueue
393389
* @flags: WQ_* flags
394-
* @max_active: max in-flight work items, 0 for default
390+
* @max_active: max in-flight work items per CPU, 0 for default
395391
* remaining args: args for @fmt
396392
*
397393
* Allocate a workqueue with the specified parameters. For detailed

0 commit comments

Comments
 (0)