From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Krzysztof Oledzki <olel@ans.pl>
Cc: Arjan van de Ven <arjan@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: IRQ handling difference between i386 and x86_64
Date: Mon, 02 Jul 2007 16:46:31 +0530 [thread overview]
Message-ID: <4688DE8F.4040902@linux.vnet.ibm.com> (raw)
In-Reply-To: <1183218035.2894.13.camel@laptopd505.fenrus.org>
Arjan van de Ven wrote:
> On Sat, 2007-06-30 at 16:55 +0200, Krzysztof Oledzki wrote:
>> Hello,
>>
>> It seems that IRQ handling is somehow different between i386 and x86_64.
>>
>> In my Dell PowerEdge 1950 is it possible to enable interrupts spreading
>> over all CPUs. This a single CPU, four CORE system (Quad-Core E5335 Xeon)
>> so I think that interrupts migration may be useful. Unfortunately, it
>> works only with 32-bit kernel. Booting it with x86_64 leads to situation,
>> when all interrupts goes only to the first cpu matching a smp_affinity
>> mask.
>
> arguably that is the most efficient behavior... round robin of
> interrupts is the worst possible case in terms of performance
>
> are you using irqbalance ? (www.irqbalance.org)
If you have not been using irqbalance, then setting more bits in
irq/smp_affinity will utilize hardware APIC routing. Sending interrupt
to more than one CPU will work in flat mode only.
In 32 bit kernel the IOAPIC is configured in flat mode while in 64 bit
it is in physical flat mode. Physical flat mode will support
interrupt routing to only one CPU.
32-bit: Enabling APIC mode: Flat. Using 2 I/O APICs
64-bit: Setting APIC routing to physical flat
This is the reason for the observed interrupt routing behavior. I
guess future kernels will use 'physical flat' mode to avoid hardware
bugs on various complex configurations and also make it scale up to
larger systems. Also utilizing hardware routing to send interrupts to
many CPUs may not provide desired behavior.
irqbalance application will do the needful. I agree with Arjan on the
fact that equal interrupt distribution need not provide best
performance. You will run into complex routing issues only when you
have more NICs than actual number of CPU cores.
--Vaidy
prev parent reply other threads:[~2007-07-02 11:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-30 14:55 IRQ handling difference between i386 and x86_64 Krzysztof Oledzki
2007-06-30 15:40 ` Arjan van de Ven
2007-06-30 22:53 ` Krzysztof Oledzki
2007-07-01 22:05 ` Chris Snook
2007-07-02 15:16 ` Eric W. Biederman
2007-07-02 11:16 ` Vaidyanathan Srinivasan [this message]
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=4688DE8F.4040902@linux.vnet.ibm.com \
--to=svaidy@linux.vnet.ibm.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olel@ans.pl \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox