From: Lai Jiangshan <jiangshan.ljs@antgroup.com>

So that its size is reduced from 40 to 32 in 64bit kernel, and it can be
saved more when allocated with kmalloc() in alloc_workqueue_attrs().

Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com>
---
 include/linux/workqueue.h | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 158784dd189a..c885a5f6bb93 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -145,13 +145,15 @@ struct workqueue_attrs {
 	int nice;
 
 	/**
-	 * @cpumask: allowed CPUs
+	 * @affn_strict: affinity scope is strict
 	 *
-	 * Work items in this workqueue are affine to these CPUs and not allowed
-	 * to execute on other CPUs. A pool serving a workqueue must have the
-	 * same @cpumask.
+	 * If clear, workqueue will make a best-effort attempt at starting the
+	 * worker inside @__pod_cpumask but the scheduler is free to migrate it
+	 * outside.
+	 *
+	 * If set, workers are only allowed to run inside @__pod_cpumask.
 	 */
-	cpumask_var_t cpumask;
+	bool affn_strict;
 
 	/**
 	 * @__pod_cpumask: internal attribute used to create per-pod pools
@@ -166,15 +168,13 @@ struct workqueue_attrs {
 	cpumask_var_t __pod_cpumask;
 
 	/**
-	 * @affn_strict: affinity scope is strict
-	 *
-	 * If clear, workqueue will make a best-effort attempt at starting the
-	 * worker inside @__pod_cpumask but the scheduler is free to migrate it
-	 * outside.
+	 * @cpumask: allowed CPUs
 	 *
-	 * If set, workers are only allowed to run inside @__pod_cpumask.
+	 * Work items in this workqueue are affine to these CPUs and not allowed
+	 * to execute on other CPUs. A pool serving a workqueue must have the
+	 * same @cpumask.
 	 */
-	bool affn_strict;
+	cpumask_var_t cpumask;
 
 	/*
 	 * Below fields aren't properties of a worker_pool. They only modify how
-- 
2.19.1.6.gb485710b

Hello,

On Fri, Mar 08, 2024 at 05:42:51PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan <jiangshan.ljs@antgroup.com>
> 
> So that its size is reduced from 40 to 32 in 64bit kernel, and it can be
> saved more when allocated with kmalloc() in alloc_workqueue_attrs().

Does this matter tho? Also, the sizing would be dependent on the number of
supported CPUs, right?

So, before, the order was - nice, cpumasks, affinity scope related stuff,
and then ordered flag. After, the cpumasks and affinity scope stuff are
mixed. Unless the saving is actually meaningful, I'd rather keep the current
ordering.

Thanks.

-- 
tejun