From: ebiederm@xmission.com (Eric W. Biederman)
To: Yinghai Lu <yinghai@kernel.org>
Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
NetDEV list <netdev@vger.kernel.org>,
Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: Re: [PATCH 2/2] x86: get more exact nr_irqs
Date: Mon, 04 Jan 2010 08:55:56 -0800 [thread overview]
Message-ID: <m1fx6lizc3.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4B41918D.3000605@kernel.org> (Yinghai Lu's message of "Sun\, 03 Jan 2010 22\:58\:21 -0800")
Yinghai Lu <yinghai@kernel.org> writes:
> first check with NR_VECTORS - FIRST_EXTERNAL_VECTOR - 0x20
> aka minus exceptions and system vectors.
>
> NR_CPUS = 512, and nr_cpu_ids = 128
> will have NR_IRQS = 256 + 512 * 64 = 33024
>
> assume we have 20 intel ixgbe 6 port cards (with sriov and ixgbevf)
> 20 * 6 * 64 * 3 = 23040
>
> first will get:
> 128 * (256 - 64) = 24576
> then with nr_irqs_gsi will get
> (120 + 8 * 128 + 120 * 256) = 31864
>
> so 24576 will be used for nr_irqs.
>
> 24576 * 8 = 196608 bytes will be used for irq_desc_ptrs[]
>
> before this patch:
> have nr_irqs = 120 + 8 * 128 + 120 * 64 = 8824
> and irq_desc_ptrs[] is 70592
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
I am lost. arch_probe_nr_irqs appears to be total nonsense.
We have three concepts.
- The number of irq sources we can talk about. ( nr_irqs)
- The number of irqs we can possibly service. ((NR_VECTORS - 0x30) *nr_cpu_ids)
- The number of irqs we actually connected up to cards in the
system that we need to do something with.
Why do we need to allocate arrays at all?
arch_probe_nr_irqs looks like a pile of magic numbers (even more magic
with the addition of 0x20), that is always going to be a little bit
wrong.
We should be able to remove the arrays all together and allocate
irq_desc dynamically.
> ---
> arch/x86/kernel/apic/io_apic.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/apic/io_apic.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/io_apic.c
> +++ linux-2.6/arch/x86/kernel/apic/io_apic.c
> @@ -3833,15 +3833,20 @@ int __init arch_probe_nr_irqs(void)
> {
> int nr;
>
> - if (nr_irqs > (NR_VECTORS * nr_cpu_ids))
> - nr_irqs = NR_VECTORS * nr_cpu_ids;
> + /* 0x20 for ipi etc system vectors */
> + nr = NR_VECTORS - FIRST_EXTERNAL_VECTOR - 0x20;
If you are going to subtract of the number of ipis please
put appropriate defines in irq_vectors.h. A raw 0x20 is
wrong.
> +
> + nr *= nr_cpu_ids;
> +
> + if (nr < nr_irqs)
> + nr_irqs = nr;
> nr = nr_irqs_gsi + 8 * nr_cpu_ids;
> #if defined(CONFIG_PCI_MSI) || defined(CONFIG_HT_IRQ)
> /*
> * for MSI and HT dyn irq
> */
> - nr += nr_irqs_gsi * 64;
> + nr += nr_irqs_gsi * 256;
This part seems like magic voodoo. Why should their
be a correlation between the number of gsis and the number
of msis?
Eric
next prev parent reply other threads:[~2010-01-04 16:56 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-25 8:42 [PATCH] x86: increase NR_IRQS and nr_irqs Yinghai Lu
2009-12-28 9:47 ` Ingo Molnar
2009-12-29 5:08 ` [PATCH -v2] " Yinghai Lu
2009-12-30 12:21 ` [tip:x86/apic] x86: Increase " tip-bot for Yinghai Lu
2010-01-04 3:06 ` [PATCH -v2] x86: increase " Jesse Brandeburg
2010-01-04 3:20 ` Yinghai Lu
2010-01-04 6:56 ` Subject: [PATCH 1/2] x86: get back 15 vectors Yinghai Lu
2010-01-04 16:18 ` Eric W. Biederman
2010-01-04 18:40 ` Yinghai Lu
2010-01-04 19:04 ` Eric W. Biederman
2010-01-04 19:14 ` H. Peter Anvin
2010-01-04 19:01 ` H. Peter Anvin
2010-01-04 19:09 ` Eric W. Biederman
2010-01-04 19:35 ` Yinghai Lu
2010-01-04 19:45 ` Suresh Siddha
2010-01-04 19:50 ` H. Peter Anvin
2010-01-05 0:05 ` Suresh Siddha
2010-01-05 0:16 ` Yinghai Lu
2010-01-05 5:30 ` [tip:x86/apic] x86, apic: Reclaim IDT vectors 0x20-0x2f tip-bot for H. Peter Anvin
2010-01-04 19:48 ` Subject: [PATCH 1/2] x86: get back 15 vectors H. Peter Anvin
2010-01-04 20:06 ` Yinghai Lu
2010-01-04 20:14 ` Eric W. Biederman
2010-01-04 20:33 ` Yinghai Lu
2010-01-04 21:10 ` H. Peter Anvin
2010-01-04 21:20 ` Yinghai Lu
2010-01-04 21:33 ` H. Peter Anvin
2010-01-04 22:01 ` Yinghai Lu
2010-01-04 23:03 ` H. Peter Anvin
2010-01-04 23:32 ` Yinghai Lu
2010-01-04 23:38 ` H. Peter Anvin
2010-01-04 23:42 ` Yinghai Lu
2010-01-04 23:49 ` Yinghai Lu
2010-01-04 23:59 ` H. Peter Anvin
2010-01-05 5:30 ` [tip:x86/apic] x86, apic: Don't waste a vector to improve vector spread tip-bot for H. Peter Anvin
2010-01-04 20:08 ` Subject: [PATCH 1/2] x86: get back 15 vectors Eric W. Biederman
2010-01-04 6:58 ` [PATCH 2/2] x86: get more exact nr_irqs Yinghai Lu
2010-01-04 16:55 ` Eric W. Biederman [this message]
2010-01-04 19:03 ` Yinghai Lu
2010-01-04 19:16 ` Eric W. Biederman
2010-01-04 19:30 ` H. Peter Anvin
2010-01-04 19:47 ` Yinghai Lu
2010-01-04 20:05 ` Eric W. Biederman
2010-01-04 21:50 ` H. Peter Anvin
2010-01-04 6:59 ` [PATCH 1/2] x86: get back 15 vectors Yinghai Lu
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=m1fx6lizc3.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jesse.brandeburg@gmail.com \
--cc=jesse.brandeburg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/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.