All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Ming Lei <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: hpa@zytor.com, linux-kernel@vger.kernel.org, hch@infradead.org,
	mingo@kernel.org, tglx@linutronix.de, axboe@kernel.dk,
	loberman@redhat.com, hch@lst.de, ming.lei@redhat.com
Subject: [tip:irq/core] genirq/affinity: Spread irq vectors among present CPUs as far as possible
Date: Fri, 6 Apr 2018 14:54:20 -0700	[thread overview]
Message-ID: <tip-d3056812e7dfe6bf4f8ad9e397a9116dd5d32d15@git.kernel.org> (raw)
In-Reply-To: <20180308105358.1506-5-ming.lei@redhat.com>

Commit-ID:  d3056812e7dfe6bf4f8ad9e397a9116dd5d32d15
Gitweb:     https://git.kernel.org/tip/d3056812e7dfe6bf4f8ad9e397a9116dd5d32d15
Author:     Ming Lei <ming.lei@redhat.com>
AuthorDate: Thu, 8 Mar 2018 18:53:58 +0800
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 6 Apr 2018 12:19:51 +0200

genirq/affinity: Spread irq vectors among present CPUs as far as possible

Commit 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs")
tried to spread the interrupts accross all possible CPUs to make sure that
in case of phsyical hotplug (e.g. virtualization) the CPUs which get
plugged in after the device was initialized are targeted by a hardware
queue and the corresponding interrupt.

This has a downside in cases where the ACPI tables claim that there are
more possible CPUs than present CPUs and the number of interrupts to spread
out is smaller than the number of possible CPUs. These bogus ACPI tables
are unfortunately not uncommon.

In such a case the vector spreading algorithm assigns interrupts to CPUs
which can never be utilized and as a consequence these interrupts are
unused instead of being mapped to present CPUs. As a result the performance
of the device is suboptimal.

To fix this spread the interrupt vectors in two stages:

 1) Spread as many interrupts as possible among the present CPUs

 2) Spread the remaining vectors among non present CPUs

On a 8 core system, where CPU 0-3 are present and CPU 4-7 are not present,
for a device with 4 queues the resulting interrupt affinity is:

  1) Before 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs")
	irq 39, cpu list 0
	irq 40, cpu list 1
	irq 41, cpu list 2
	irq 42, cpu list 3

  2) With 84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs")
	irq 39, cpu list 0-2
	irq 40, cpu list 3-4,6
	irq 41, cpu list 5
	irq 42, cpu list 7

  3) With the refined vector spread applied:
	irq 39, cpu list 0,4
	irq 40, cpu list 1,6
	irq 41, cpu list 2,5
	irq 42, cpu list 3,7

On a 8 core system, where all CPUs are present the resulting interrupt
affinity for the 4 queues is:

	irq 39, cpu list 0,1
	irq 40, cpu list 2,3
	irq 41, cpu list 4,5
	irq 42, cpu list 6,7

This is independent of the number of CPUs which are online at the point of
initialization because in such a system the offline CPUs can be easily
onlined afterwards, while in non-present CPUs need to be plugged physically
or virtually which requires external interaction.

The downside of this approach is that in case of physical hotplug the
interrupt vector spreading might be suboptimal when CPUs 4-7 are physically
plugged. Suboptimal from a NUMA point of view and due to the single target
nature of interrupt affinities the later plugged CPUs might not be targeted
by interrupts at all.

Though, physical hotplug systems are not the common case while the broken
ACPI table disease is wide spread. So it's preferred to have as many
interrupts as possible utilized at the point where the device is
initialized.

Block multi-queue devices like NVME create a hardware queue per possible
CPU, so the goal of commit 84676c1f21 to assign one interrupt vector per
possible CPU is still achieved even with physical/virtual hotplug.

[ tglx: Changed from online to present CPUs for the first spreading stage,
  	renamed variables for readability sake, added comments and massaged
  	changelog ]

Reported-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Link: https://lkml.kernel.org/r/20180308105358.1506-5-ming.lei@redhat.com

---
 kernel/irq/affinity.c | 43 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 213695a27ddb..f4f29b9d90ee 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -106,6 +106,9 @@ static int irq_build_affinity_masks(const struct irq_affinity *affd,
 	int curvec = startvec;
 	nodemask_t nodemsk = NODE_MASK_NONE;
 
+	if (!cpumask_weight(cpu_mask))
+		return 0;
+
 	nodes = get_nodes_in_cpumask(node_to_cpumask, cpu_mask, &nodemsk);
 
 	/*
@@ -173,8 +176,9 @@ out:
 struct cpumask *
 irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 {
-	int curvec, affvecs = nvecs - affd->pre_vectors - affd->post_vectors;
-	cpumask_var_t nmsk, *node_to_cpumask;
+	int affvecs = nvecs - affd->pre_vectors - affd->post_vectors;
+	int curvec, usedvecs;
+	cpumask_var_t nmsk, npresmsk, *node_to_cpumask;
 	struct cpumask *masks = NULL;
 
 	/*
@@ -187,9 +191,12 @@ irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 	if (!zalloc_cpumask_var(&nmsk, GFP_KERNEL))
 		return NULL;
 
+	if (!zalloc_cpumask_var(&npresmsk, GFP_KERNEL))
+		goto outcpumsk;
+
 	node_to_cpumask = alloc_node_to_cpumask();
 	if (!node_to_cpumask)
-		goto outcpumsk;
+		goto outnpresmsk;
 
 	masks = kcalloc(nvecs, sizeof(*masks), GFP_KERNEL);
 	if (!masks)
@@ -202,16 +209,40 @@ irq_create_affinity_masks(int nvecs, const struct irq_affinity *affd)
 	/* Stabilize the cpumasks */
 	get_online_cpus();
 	build_node_to_cpumask(node_to_cpumask);
-	curvec += irq_build_affinity_masks(affd, curvec, affvecs,
-					   node_to_cpumask, cpu_possible_mask,
-					   nmsk, masks);
+
+	/* Spread on present CPUs starting from affd->pre_vectors */
+	usedvecs = irq_build_affinity_masks(affd, curvec, affvecs,
+					    node_to_cpumask, cpu_present_mask,
+					    nmsk, masks);
+
+	/*
+	 * Spread on non present CPUs starting from the next vector to be
+	 * handled. If the spreading of present CPUs already exhausted the
+	 * vector space, assign the non present CPUs to the already spread
+	 * out vectors.
+	 */
+	if (usedvecs >= affvecs)
+		curvec = affd->pre_vectors;
+	else
+		curvec = affd->pre_vectors + usedvecs;
+	cpumask_andnot(npresmsk, cpu_possible_mask, cpu_present_mask);
+	usedvecs += irq_build_affinity_masks(affd, curvec, affvecs,
+					     node_to_cpumask, npresmsk,
+					     nmsk, masks);
 	put_online_cpus();
 
 	/* Fill out vectors at the end that don't need affinity */
+	if (usedvecs >= affvecs)
+		curvec = affd->pre_vectors + affvecs;
+	else
+		curvec = affd->pre_vectors + usedvecs;
 	for (; curvec < nvecs; curvec++)
 		cpumask_copy(masks + curvec, irq_default_affinity);
+
 outnodemsk:
 	free_node_to_cpumask(node_to_cpumask);
+outnpresmsk:
+	free_cpumask_var(npresmsk);
 outcpumsk:
 	free_cpumask_var(nmsk);
 	return masks;

  parent reply	other threads:[~2018-04-06 21:54 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 10:53 [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible Ming Lei
2018-03-08 10:53 ` [PATCH V3 1/4] genirq/affinity: rename *node_to_possible_cpumask as *node_to_cpumask Ming Lei
2018-04-06 21:52   ` [tip:irq/core] genirq/affinity: Rename " tip-bot for Ming Lei
2018-03-08 10:53 ` [PATCH V3 2/4] genirq/affinity: move actual irq vector spread into one helper Ming Lei
2018-04-06 21:53   ` [tip:irq/core] genirq/affinity: Move actual irq vector spreading into a helper function tip-bot for Ming Lei
2018-03-08 10:53 ` [PATCH V3 3/4] genirq/affinity: support to do irq vectors spread starting from any vector Ming Lei
2018-04-06 21:53   ` [tip:irq/core] genirq/affinity: Allow irq spreading from a given starting point tip-bot for Ming Lei
2018-03-08 10:53 ` [PATCH V3 4/4] genirq/affinity: irq vector spread among online CPUs as far as possible Ming Lei
2018-04-03 13:32   ` Thomas Gleixner
2018-04-03 16:00     ` Ming Lei
2018-04-04  8:25       ` Thomas Gleixner
2018-04-04 12:45         ` Thomas Gleixner
2018-04-04 15:20           ` Ming Lei
2018-04-05 10:12             ` Thomas Gleixner
2018-04-04 15:08         ` Ming Lei
2018-04-04 19:38           ` Thomas Gleixner
2018-04-06  9:13             ` Ming Lei
2018-04-06  9:46               ` Thomas Gleixner
2018-04-06 21:49                 ` Thomas Gleixner
2018-04-08  3:19                   ` Ming Lei
2018-04-06 21:54   ` tip-bot for Ming Lei [this message]
2018-03-08 13:18 ` [PATCH V3 0/4] " Artem Bityutskiy
2018-03-08 13:25   ` Artem Bityutskiy
2018-03-08 13:34   ` Ming Lei
2018-03-08 23:20     ` Thomas Gleixner
2018-03-09  1:24       ` Ming Lei
2018-03-09  7:00         ` Artem Bityutskiy
2018-03-09  7:33           ` Ming Lei
2018-03-09 10:08         ` Thomas Gleixner
2018-03-09 12:08           ` Ming Lei
2018-03-09 15:08             ` Thomas Gleixner
2018-03-13  3:11               ` Dou Liyang
2018-03-13  7:38                 ` Artem Bityutskiy
2018-03-13  7:38                   ` Artem Bityutskiy
2018-03-13  8:35                   ` Ming Lei
2018-03-13  8:39                     ` Artem Bityutskiy
2018-03-13  8:39                       ` Artem Bityutskiy
2018-03-13  9:35                       ` Rafael J. Wysocki
2018-03-14  3:29                         ` Dou Liyang
2018-03-14  4:11                           ` Dou Liyang
2018-03-14  9:07                             ` Artem Bityutskiy
2018-03-14  9:47                               ` Dou Liyang
2018-03-13  9:25                 ` Rafael J. Wysocki
2018-03-14  3:30                   ` Dou Liyang
2018-03-30  3:15               ` Ming Lei
2018-04-03 12:55                 ` Thomas Gleixner
2018-03-26  8:39   ` Thorsten Leemhuis
2018-03-28  6:15     ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tip-d3056812e7dfe6bf4f8ad9e397a9116dd5d32d15@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=loberman@redhat.com \
    --cc=ming.lei@redhat.com \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.