Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1611430 > unrolled thread

[PATCH] irq/affinity: Assign all CPUs a vector

Back to article view | Back to linux.kernel

Contents

  [PATCH] irq/affinity: Assign all CPUs a vector Keith Busch <keith.busch@intel.com> - 2017-03-29 01:20 +0200
    Re: [PATCH] irq/affinity: Assign all CPUs a vector Sagi Grimberg <sagi@grimberg.me> - 2017-03-29 19:20 +0200
      Re: [PATCH] irq/affinity: Assign all CPUs a vector Keith Busch <keith.busch@intel.com> - 2017-03-29 19:50 +0200
        Re: [PATCH] irq/affinity: Assign all CPUs a vector Sagi Grimberg <sagi@grimberg.me> - 2017-03-29 20:00 +0200
    Re: [PATCH] irq/affinity: Assign all CPUs a vector Christoph Hellwig <hch@lst.de> - 2017-03-30 10:30 +0200
      Re: [PATCH] irq/affinity: Assign all CPUs a vector Keith Busch <keith.busch@intel.com> - 2017-03-30 19:10 +0200
    Re: [PATCH] irq/affinity: Assign all CPUs a vector Thomas Gleixner <tglx@linutronix.de> - 2017-03-31 13:10 +0200

#1611430 — [PATCH] irq/affinity: Assign all CPUs a vector

The number of vectors to assign needs to be adjusted for each node such
that it doesn't exceed the number of CPUs in that node. This patch
recalculates the vector assignment per-node so that we don't try to
assign more vectors than there are CPUs. When that previously happened,
the cpus_per_vec was calculated to be 0, so many vectors had no CPUs
assigned. This then goes on to fail to allocate descriptors due to
empty masks, leading to an unoptimal spread.

Not only does this patch get the intended spread, this also fixes
other subsystems that depend on every CPU being assigned to something:
blk_mq_map_swqueue dereferences NULL while mapping s/w queues when CPUs
are unnassigned, so making sure all CPUs are assigned fixes that.

Signed-off-by: Keith Busch <keith.busch@intel.com>
---
 kernel/irq/affinity.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 4544b11..dc52911 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -59,7 +59,7 @@ static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t *nodemsk)
 struct cpumask *
 irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 {
-	int n, nodes, vecs_per_node, cpus_per_vec, extra_vecs, curvec;
+	int n, nodes, cpus_per_vec, extra_vecs, curvec;
 	int affv = nvecs - affd->pre_vectors - affd->post_vectors;
 	int last_affv = affv + affd->pre_vectors;
 	nodemask_t nodemsk = NODE_MASK_NONE;
@@ -94,19 +94,21 @@ irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 		goto done;
 	}
 
-	/* Spread the vectors per node */
-	vecs_per_node = affv / nodes;
-	/* Account for rounding errors */
-	extra_vecs = affv - (nodes * vecs_per_node);
-
 	for_each_node_mask(n, nodemsk) {
-		int ncpus, v, vecs_to_assign = vecs_per_node;
+		int ncpus, v, vecs_to_assign, vecs_per_node;
+
+		/* Spread the vectors per node */
+		vecs_per_node = (affv - curvec) / nodes;
 
 		/* Get the cpus on this node which are in the mask */
 		cpumask_and(nmsk, cpu_online_mask, cpumask_of_node(n));
 
 		/* Calculate the number of cpus per vector */
 		ncpus = cpumask_weight(nmsk);
+		vecs_to_assign = min(vecs_per_node, ncpus);
+
+		/* Account for rounding errors */
+		extra_vecs = ncpus - vecs_to_assign;
 
 		for (v = 0; curvec < last_affv && v < vecs_to_assign;
 		     curvec++, v++) {
@@ -115,14 +117,14 @@ irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 			/* Account for extra vectors to compensate rounding errors */
 			if (extra_vecs) {
 				cpus_per_vec++;
-				if (!--extra_vecs)
-					vecs_per_node++;
+				--extra_vecs;
 			}
 			irq_spread_init_one(masks + curvec, nmsk, cpus_per_vec);
 		}
 
 		if (curvec >= last_affv)
 			break;
+		--nodes;
 	}
 
 done:
-- 
2.7.2

[toc] | [next] | [standalone]

#1612167

> The number of vectors to assign needs to be adjusted for each node such
> that it doesn't exceed the number of CPUs in that node. This patch
> recalculates the vector assignment per-node so that we don't try to
> assign more vectors than there are CPUs. When that previously happened,
> the cpus_per_vec was calculated to be 0, so many vectors had no CPUs
> assigned. This then goes on to fail to allocate descriptors due to
> empty masks, leading to an unoptimal spread.

Can you give a specific (numeric) example where this happens? I'm having
a little trouble following the logical change here.

[toc] | [prev] | [next] | [standalone]

#1612188

On Wed, Mar 29, 2017 at 08:15:50PM +0300, Sagi Grimberg wrote:
> 
> > The number of vectors to assign needs to be adjusted for each node such
> > that it doesn't exceed the number of CPUs in that node. This patch
> > recalculates the vector assignment per-node so that we don't try to
> > assign more vectors than there are CPUs. When that previously happened,
> > the cpus_per_vec was calculated to be 0, so many vectors had no CPUs
> > assigned. This then goes on to fail to allocate descriptors due to
> > empty masks, leading to an unoptimal spread.
> 
> Can you give a specific (numeric) example where this happens? I'm having
> a little trouble following the logical change here.

Sure, I have a 2-socket server with 16 threads each. I take one CPU
offline in socket 2, so I've 16 threads on socket 1, 15 in socket 2. In
total, 31 threads so requesting 31 vectors.

Currently, vecs_per_node is calculated in the first iteration as 31 / 2, so 15.

ncpus of socket 1 is 16. cpus_per_vec = 16 / 15, so 1 CPU per vector
with one extra.

When iterating the second socket, though, vecs_per_node is incremented
from 15 to 16 (to account for the "extra" from before). However, the
ncpus is only 15, so that iteration calculates:

  cpus_per_vec = 15 / 16

And since that's zero, the remaining 16 vectors are not assigned to any
CPU, and the second socket has no vectors assigned to their CPUs.

[toc] | [prev] | [next] | [standalone]

#1612214

> Sure, I have a 2-socket server with 16 threads each. I take one CPU
> offline in socket 2, so I've 16 threads on socket 1, 15 in socket 2. In
> total, 31 threads so requesting 31 vectors.
>
> Currently, vecs_per_node is calculated in the first iteration as 31 / 2, so 15.
>
> ncpus of socket 1 is 16. cpus_per_vec = 16 / 15, so 1 CPU per vector
> with one extra.
>
> When iterating the second socket, though, vecs_per_node is incremented
> from 15 to 16 (to account for the "extra" from before). However, the
> ncpus is only 15, so that iteration calculates:
>
>   cpus_per_vec = 15 / 16
>
> And since that's zero, the remaining 16 vectors are not assigned to any
> CPU, and the second socket has no vectors assigned to their CPUs.

Thanks for the clarification, makes sense...

Reviewed-by: Sagi Grimberg <sagi@grimberg.me>

[toc] | [prev] | [next] | [standalone]

#1612715

Looks fine,

Reviewed-by: Christoph Hellwig <hch@lst.de>

[toc] | [prev] | [next] | [standalone]

#1613304

[Multipart message — attachments visible in raw view] — view raw

Hi Thomas,

I received an email delivery failure on the original patch, so I'm not
sure if you got it. I'm reattaching here with the two reviews just in
case. Please let me know if you've any concerns with the proposal.

Thanks,
Keith

[toc] | [prev] | [next] | [standalone]

#1613874

On Tue, 28 Mar 2017, Keith Busch wrote:

> The number of vectors to assign needs to be adjusted for each node such
> that it doesn't exceed the number of CPUs in that node. This patch
> recalculates the vector assignment per-node so that we don't try to
> assign more vectors than there are CPUs. When that previously happened,
> the cpus_per_vec was calculated to be 0, so many vectors had no CPUs
> assigned. This then goes on to fail to allocate descriptors due to
> empty masks, leading to an unoptimal spread.

To be honest: This changelog sucks. I really have a hard time to figure out
what's wrong. Can you please structure and rephrase this so it's
understandable for people who did not debug the issue five days ago? That
includes yourself when you have to look at that patch 3 month from now.

A proper structure would be: Context - Problem - Solution. e.g.

  irq_create_affinity_masks() spreads the interrupt vectors of a multi
  queue device across CPUs.

  The algorithm fails to do X, which causes problem Y

  Make it do frotz so the blas are properly assigned.

> Not only does this patch get the intended spread, this also fixes
> other subsystems that depend on every CPU being assigned to something:
> blk_mq_map_swqueue dereferences NULL while mapping s/w queues when CPUs
> are unnassigned, so making sure all CPUs are assigned fixes that.

That's hardly a justification for that change. If blk_mq_map_swqueue()
lacks sanity checks, then blk_mq_map_swqueue() is broken and needs to be
fixed independently of this.

Thanks,

	tglx

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web