For historical reason, wq_unbound_cpumask is initially set as
intersection of HK_TYPE_DOMAIN, HK_TYPE_WQ and workqueue.unbound_cpus
boot command line option.

At run time, users can update the unbound cpumask via the
/sys/devices/virtual/workqueue/cpumask sysfs file. Creation
and modification of cpuset isolated partitions will also update
wq_unbound_cpumask based on the latest HK_TYPE_DOMAIN cpumask.
The HK_TYPE_WQ cpumask is out of the picture with these runtime updates.

Complete the transition by taking HK_TYPE_WQ out from the workqueue code
and make it depends on HK_TYPE_DOMAIN only from the housekeeping side.
The final goal is to eliminate HK_TYPE_WQ as a housekeeping cpumask type.

Signed-off-by: Waiman Long <longman@redhat.com>
---
 kernel/workqueue.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index e5f69377f0cc..aa8e82439c9f 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -7084,7 +7084,7 @@ int workqueue_unbound_housekeeping_update(const struct cpumask *hk)
 	/*
 	 * If the operation fails, it will fall back to
 	 * wq_requested_unbound_cpumask which is initially set to
-	 * (HK_TYPE_WQ ∩ HK_TYPE_DOMAIN) house keeping mask and rewritten
+	 * HK_TYPE_DOMAIN house keeping mask and rewritten
 	 * by any subsequent write to workqueue/cpumask sysfs file.
 	 */
 	if (!cpumask_and(cpumask, wq_requested_unbound_cpumask, hk))
@@ -7921,7 +7921,6 @@ void __init workqueue_init_early(void)
 
 	cpumask_copy(wq_online_cpumask, cpu_online_mask);
 	cpumask_copy(wq_unbound_cpumask, cpu_possible_mask);
-	restrict_unbound_cpumask("HK_TYPE_WQ", housekeeping_cpumask(HK_TYPE_WQ));
 	restrict_unbound_cpumask("HK_TYPE_DOMAIN", housekeeping_cpumask(HK_TYPE_DOMAIN));
 	if (!cpumask_empty(&wq_cmdline_cpumask))
 		restrict_unbound_cpumask("workqueue.unbound_cpus", &wq_cmdline_cpumask);
-- 
2.53.0

Applied to wq/for-7.1.

Thanks.

--
tejun

Le Tue, Mar 31, 2026 at 02:35:22PM -0400, Waiman Long a écrit :
> For historical reason, wq_unbound_cpumask is initially set as
> intersection of HK_TYPE_DOMAIN, HK_TYPE_WQ and workqueue.unbound_cpus
> boot command line option.
> 
> At run time, users can update the unbound cpumask via the
> /sys/devices/virtual/workqueue/cpumask sysfs file. Creation
> and modification of cpuset isolated partitions will also update
> wq_unbound_cpumask based on the latest HK_TYPE_DOMAIN cpumask.
> The HK_TYPE_WQ cpumask is out of the picture with these runtime updates.
> 
> Complete the transition by taking HK_TYPE_WQ out from the workqueue code
> and make it depends on HK_TYPE_DOMAIN only from the housekeeping side.
> The final goal is to eliminate HK_TYPE_WQ as a housekeeping cpumask type.
> 
> Signed-off-by: Waiman Long <longman@redhat.com>

Acked-by: Frederic Weisbecker <frederic@kernel.org>

-- 
Frederic Weisbecker
SUSE Labs

On Tue, Mar 31, 2026 at 02:35:22PM -0400, Waiman Long wrote:
> For historical reason, wq_unbound_cpumask is initially set as
> intersection of HK_TYPE_DOMAIN, HK_TYPE_WQ and workqueue.unbound_cpus
> boot command line option.
> 
> At run time, users can update the unbound cpumask via the
> /sys/devices/virtual/workqueue/cpumask sysfs file. Creation
> and modification of cpuset isolated partitions will also update
> wq_unbound_cpumask based on the latest HK_TYPE_DOMAIN cpumask.
> The HK_TYPE_WQ cpumask is out of the picture with these runtime updates.
> 
> Complete the transition by taking HK_TYPE_WQ out from the workqueue code
> and make it depends on HK_TYPE_DOMAIN only from the housekeeping side.
> The final goal is to eliminate HK_TYPE_WQ as a housekeeping cpumask type.
> 
> Signed-off-by: Waiman Long <longman@redhat.com>

Looks fine to me but imma wait for Frederic's review.

Thanks.

-- 
tejun