summaryrefslogtreecommitdiff
path: root/include/linux/stacktrace.h
diff options
context:
space:
mode:
authorBreno Leitao <leitao@debian.org>2026-09-10 07:54:12 -0700
committerTejun Heo <tj@kernel.org>2026-09-10 11:47:51 -1000
commit27db9dd7f84f3a7704596455b508611da3d6269d (patch)
tree2184269c34ea50c79039d7c8f95144c4dc685812 /include/linux/stacktrace.h
parentf1639cde5f5c1bee25498ef988227ee8cf5ddb04 (diff)
downloadlinux-next-27db9dd7f84f3a7704596455b508611da3d6269d.tar.gz
linux-next-27db9dd7f84f3a7704596455b508611da3d6269d.zip
workqueue: Give percpu workqueues their own max_active
wq->max_active means two different things, depending on how the workqueue is backed. On a concurrency managed per-cpu pool it caps pwq->nr_active, so it is a per-cpu limit. On an unbound pool it feeds wq_node_nr_active() and is shared by the whole workqueue. Tejun once said [1]: It kinda sucks that max_active's meaning is different across the boundary tho. Maybe percpu max_active should be separate into its own field, idk. Add wq->percpu_max_active for the first meaning and leave max_active as the system wide one. wq_adjust_max_active() updates whichever of the two applies, and min_active stays with max_active as only the unbound side uses it. Suggested-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/all/amESSqf0TMmzhFGz@slm.duckdns.org/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'include/linux/stacktrace.h')
0 files changed, 0 insertions, 0 deletions