On NUMA systems with dynamic processors, the content of the cpumask
may change over time. As new processors are added via DLPAR operations,
workqueues are created for them. Depending upon the order in which CPUs
are added/removed, we may run into problems with the content of the
cpumask used by the workqueues. This patch deals with situations where
the online cpumask for a node is a proper superset of possible cpumask
for the node. It also deals with edge cases where the order in which
CPUs are removed/added from the online cpumask may leave the set for a
node empty, and require execution by CPUs on another node.
In these and other cases, the patch attempts to ensure that a valid,
usable cpumask is used to set up newly created pools for workqueues.
[With additions to the patch provided by Tejun Hao <[email protected]>]
Signed-off-by: Michael Bringmann <[email protected]>
---
Changes in V5:
-- Revise the warning notification.
---
kernel/workqueue.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c74bf39..6b6d540 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3577,6 +3577,13 @@ static bool wq_calc_node_cpumask(const struct workqueue_attrs *attrs, int node,
/* yeap, return possible CPUs in @node that @attrs wants */
cpumask_and(cpumask, attrs->cpumask, wq_numa_possible_cpumask[node]);
+
+ if (cpumask_empty(cpumask)) {
+ pr_warn_once("WARNING: workqueue cpumask: onl intersect > "
+ "possible intersect\n");
+ return false;
+ }
+
return !cpumask_equal(cpumask, attrs->cpumask);
use_dfl:
Hello, Michael.
On Thu, Jul 27, 2017 at 12:06:22PM -0500, Michael Bringmann wrote:
>
> On NUMA systems with dynamic processors, the content of the cpumask
> may change over time. As new processors are added via DLPAR operations,
> workqueues are created for them. Depending upon the order in which CPUs
> are added/removed, we may run into problems with the content of the
> cpumask used by the workqueues. This patch deals with situations where
> the online cpumask for a node is a proper superset of possible cpumask
> for the node. It also deals with edge cases where the order in which
> CPUs are removed/added from the online cpumask may leave the set for a
> node empty, and require execution by CPUs on another node.
I think we already talked about this before but can you please note
that this is a bandaid to workaround an underlying bug. This isn't
something which normally happens on NUMA sytems with dynamic
processors. This is bandaiding a hole so that the machine at least
doesn't crash immediately until we can get the underlying problem
fixed properly.
Thanks.
--
tejun