[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 6/6] x86/irq: do not set nr_irqs based on nr_irqs_gsi in APIC mode


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 5 Jul 2022 16:22:11 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FDdtPKbPrMYdL9fmjw8kpdIPCiiqjZbIe+Ynkepvz7U=; b=dBKCKpaMpyeefwDBSNbSdzzy3k12la0i3g2KFlWvpwSw7h0oierNIw7bvryEOTovryyVoiLwHSNTDvU/0w0QNPIwa/ovhcMD2fH4K5/JnyeZoizdn3kHVfy3iH0uX3uyJ0AWjjOMVknwxZj2P/dbk0t2Nv1Hztc/r4/VLjHLVKms8J1gWJ6tgxObtE0gJjDkT7HBhq4h0XhrLqwdySHyHrwU9/FrQpL+kLBd2unhf0W2GVa7ELvf9Y7C6wZbgHgdnqR/msarTlqcNc+XuSNde7x/ovmZIDwz1U4qvoUDNEslBCfcwtkXC9/D+N/jw1ZDFb8hhkwlofDGGQhmXagoOQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A/ImTp7D3Q+ADopOx0pUDj9r7mEJ4CTX1Akuun7sRWKIP+sDe9G3sfffxw5SJCQxWRXYflTvpDl17Gv7BKK9zSpgDzzJ2j4yBXmLxaRQqTTMUU9xO2lzV+sLK4CKuK/ermNtDbZKYZ+4PFpSYOBpHSN4hzAPp0VjG2Gtjk1q7Vmq3BSPvpIMvrGi63kqJ4GSFbNYGIuW/AyMTitKLbSDhbg/OgrJoYowVFT2JprOhzVJGdyYqsiBhE6sX/HFYYC9Pkyd27z9zqSepg6FKminHrtjSdeDLqrurrw67nzcEz5dCYOA+ldLGS4Wq1++lSFHVwf7jj0vVHzWuGN9h+BeYw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 05 Jul 2022 14:22:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.06.2022 10:54, Roger Pau Monne wrote:
> When using an APIC do not set nr_irqs based on a factor of nr_irqs_gsi
> (currently x8), and instead do so exclusively based on the amount of
> available vectors on the system.
> 
> There's no point in setting nr_irqs to a value higher than the
> available set of vectors, as vector allocation will fail anyway.

Only if in the earlier calculation you include hotplug CPUs.

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -426,8 +426,7 @@ int __init init_irq_data(void)
>              (x2apic_enabled && !x2apic_phys) ? x2apic_max_cluster_id + 1
>                                               : num_present_cpus();
>  
> -        nr_irqs = cpu_has_apic ? max(vec_spaces * NR_DYNAMIC_VECTORS,
> -                                     8 * nr_irqs_gsi)
> +        nr_irqs = cpu_has_apic ? vec_spaces * NR_DYNAMIC_VECTORS
>                                 : nr_irqs_gsi;

I wonder how useful it is to retain the !cpu_has_apic case here. I
don't have much hope for Xen to work properly if APIC use was
suppressed, and I'm unaware of x86-64 CPUs without APIC.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.