On Mon, 2009-09-14 at 14:48 -0700, C Storm wrote:
> In this linux mag article (http://www.linux-mag.com/cache/7516/1.html)
> the author describes a performance problem
> brought on by using the noapic boot time kernel option. Has anyone
> investigated whether postgres performs better
> with/without the noapic option?
It probably depends a lot on how your devices are arranged on the PCI
and PCIe bus(es) and how the kernel/bios assigns interrupt lines. If
busy/active devices share interrupts with other devices, especially if
those devices take significant work to poll when an interrupt is
received, it could have a nasty effect on performance. On the other
hand, if your high-load devices like NICs and disk controller(s) don't
land up sharing interrupts, AFAIK it may not make much difference. I
don't know how much difference the local APIC(s) and IO-APIC make as
compared to the 8259 PIC when shared interrupts aren't an issue.
Then again, I'm surprised any modern machine can run without an IO-APIC.
Isn't it required for SMP or multi-core operation?
This article might help provide some information. While it's about
Windows and is on MSDN, the principles it describes about how the local
APIC(s) and IO-APIC(s) help should apply equally well to Linux and other
systems.
http://www.microsoft.com/whdc/archive/io-apic.mspx
I don't think the issues with synchronization primitives really apply on
*nix systems, but the issues with interrupt latency certainly do.
As you can see from the article, having a working system of local and
I/O APICs should dramatically reduce wasted bus I/O resources and CPU
time required to service interrupts especially on highly shared
interrupt lines. Consider one of the servers here:
$ cat /proc/interrupts
CPU0 CPU1
0: 90 0 IO-APIC-edge timer
1: 16 0 IO-APIC-edge i8042
4: 1368 0 IO-APIC-edge serial
6: 3 0 IO-APIC-edge floppy
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
14: 0 0 IO-APIC-edge ide0
15: 0 0 IO-APIC-edge ide1
28: 64040415 0 IO-APIC-fasteoi 3w-xxxx
48: 668225084 0 IO-APIC-fasteoi eth1000
See how the highly active 3Ware 8500-8 (3w-xxxx) disk controller and the
Intel EtherExpress 10/100/1000 (eth1000) have their own private
interrupt lines on interrupts 28 and 48 ? Without APICs they might be
forced to share, or at least be placed on the same interrupt as (eg) a
USB controller, a PATA disk controller, or whatever. That might force
the OS to do work for those devices too when it receives an interrupt on
that IRQ line. Not ideal.
(Interestingly, this is a real dual-CPU system but all interrupts are
being serviced by the first CPU. Whoops. apt-get install irqbalance).
--
Craig Ringer
