diff options
| author | Tejun Heo <[email protected]> | 2013-09-05 16:30:04 +0000 |
|---|---|---|
| committer | Tejun Heo <[email protected]> | 2013-11-22 23:14:02 +0000 |
| commit | 8a2b75384444488fc4f2cbb9f0921b6a0794838f (patch) | |
| tree | c4b39daad8de264be08beec77621048e9b9fb9ed /lib/assoc_array.c | |
| parent | workqueue: swap set_cpus_allowed_ptr() and PF_NO_SETAFFINITY (diff) | |
| download | kernel-8a2b75384444488fc4f2cbb9f0921b6a0794838f.tar.gz kernel-8a2b75384444488fc4f2cbb9f0921b6a0794838f.zip | |
workqueue: fix ordered workqueues in NUMA setups
An ordered workqueue implements execution ordering by using single
pool_workqueue with max_active == 1. On a given pool_workqueue, work
items are processed in FIFO order and limiting max_active to 1
enforces the queued work items to be processed one by one.
Unfortunately, 4c16bd327c ("workqueue: implement NUMA affinity for
unbound workqueues") accidentally broke this guarantee by applying
NUMA affinity to ordered workqueues too. On NUMA setups, an ordered
workqueue would end up with separate pool_workqueues for different
nodes. Each pool_workqueue still limits max_active to 1 but multiple
work items may be executed concurrently and out of order depending on
which node they are queued to.
Fix it by using dedicated ordered_wq_attrs[] when creating ordered
workqueues. The new attrs match the unbound ones except that no_numa
is always set thus forcing all NUMA nodes to share the default
pool_workqueue.
While at it, add sanity check in workqueue creation path which
verifies that an ordered workqueues has only the default
pool_workqueue.
Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Libin <[email protected]>
Cc: [email protected]
Cc: Lai Jiangshan <[email protected]>
Diffstat (limited to 'lib/assoc_array.c')
0 files changed, 0 insertions, 0 deletions
