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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
