Craig, Thank you for the detailed reply. Thanks for walking me through the thought process. Also thanks for serendipitous irqbalance suggestion. Cheers On Sep 17, 1:00 am, cr...@xxxxxxxxxxxxxxxxxxxxx (Craig Ringer) wrote: > 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-performa...@xxxxxxxxxxxxxx) > To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
