From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751703AbdIMVfF (ORCPT ); Wed, 13 Sep 2017 17:35:05 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:40099 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516AbdIMVe6 (ORCPT ); Wed, 13 Sep 2017 17:34:58 -0400 Message-Id: <20170913213154.228824430@linutronix.de> User-Agent: quilt/0.63-1 Date: Wed, 13 Sep 2017 23:29:27 +0200 From: Thomas Gleixner To: LKML Cc: Ingo Molnar , Peter Anvin , Marc Zyngier , Peter Zijlstra , Borislav Petkov , Chen Yu , Rui Zhang , "Rafael J. Wysocki" , Len Brown , Dan Williams , Christoph Hellwig , Paolo Bonzini , Joerg Roedel , Boris Ostrovsky , Juergen Gross , Tony Luck , "K. Y. Srinivasan" , Alok Kataria , Steven Rostedt , Arjan van de Ven Subject: [patch 25/52] x86/apic: Get rid of multi CPU affinity References: <20170913212902.530704676@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Disposition: inline; filename=x86-apic--Get-rid-of-multi-CPU-affinity.patch Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Setting the interrupt affinity of a single interrupt to multiple CPUs has a dubious value. 1) This only works on machines where the APIC uses logical destination mode. If the APIC uses physical destination mode then it is already restricted to a single CPU 2) Experiments have shown, that the benefit of multi CPU affinity is close to zero and in some test even worse than setting the affinity to a single CPU. The reason for this is that the delivery targets the APIC with the lowest ID first and only if that APIC is busy (servicing an interrupt, i.e. ISR is not empty) it hands it over to the next APIC. In the conducted tests the vast majority of interrupts ends up on the APIC with the lowest ID anyway, so there is no natural spreading of the interrupts possible. Supporting multi CPU affinities adds a lot of complexity to the code, which can turn the allocation search into a worst case of nr_vectors * nr_online_cpus * nr_bits_in_target_mask As a first step disable it by restricting the vector search to a single CPU. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/vector.c | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -136,8 +136,7 @@ static int __assign_irq_vector(int irq, while (cpu < nr_cpu_ids) { int new_cpu, offset; - /* Get the possible target cpus for @mask/@cpu from the apic */ - apic->vector_allocation_domain(cpu, vector_cpumask, mask); + cpumask_copy(vector_cpumask, cpumask_of(cpu)); /* * Clear the offline cpus from @vector_cpumask for searching @@ -367,17 +366,11 @@ static int x86_vector_alloc_irqs(struct irq_data->chip = &lapic_controller; irq_data->chip_data = data; irq_data->hwirq = virq + i; + irqd_set_single_target(irq_data); err = assign_irq_vector_policy(virq + i, node, data, info, irq_data); if (err) goto error; - /* - * If the apic destination mode is physical, then the - * effective affinity is restricted to a single target - * CPU. Mark the interrupt accordingly. - */ - if (!apic->irq_dest_mode) - irqd_set_single_target(irq_data); } return 0; @@ -434,7 +427,7 @@ static void __init init_legacy_irqs(void BUG_ON(!data); data->cfg.vector = ISA_IRQ_VECTOR(i); - cpumask_setall(data->domain); + cpumask_copy(data->domain, cpumask_of(0)); irq_set_chip_data(i, data); } }