workqueue: Initialize unbound CPU pods later in the boot
authorTejun Heo <tj@kernel.org>
Tue, 8 Aug 2023 01:57:24 +0000 (15:57 -1000)
committerTejun Heo <tj@kernel.org>
Tue, 8 Aug 2023 01:57:24 +0000 (15:57 -1000)
commit2930155b2e27232c033970f2e110aaac4187cb9e
tree5d1c22865d7322c3cb4b8835c718cb3edcb6d670
parenta86feae6195ac2148097b063f7fdad8ee1f6dad4
workqueue: Initialize unbound CPU pods later in the boot

During boot, to initialize unbound CPU pods, wq_pod_init() was called from
workqueue_init(). This is early enough for NUMA nodes to be set up but
before SMP is brought up and CPU topology information is populated.

Workqueue is in the process of improving CPU locality for unbound workqueues
and will need access to topology information during pod init. This adds a
new init function workqueue_init_topology() which is called after CPU
topology information is available and replaces wq_pod_init().

As unbound CPU pods are now initialized after workqueues are activated, we
need to revisit the workqueues to apply the pod configuration. Workqueues
which are created before workqueue_init_topology() are set up so that they
always use the default worker pool. After pods are set up in
workqueue_init_topology(), wq_update_pod() is called on all existing
workqueues to update the pool associations accordingly.

Note that wq_update_pod_attrs_buf allocation is moved to
workqueue_init_early(). This isn't necessary right now but enables further
generalization of pod handling in the future.

This patch changes the initialization sequence but the end result should be
the same.

Signed-off-by: Tejun Heo <tj@kernel.org>
include/linux/workqueue.h
init/main.c
kernel/workqueue.c