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...@postnewspapers.com.au (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...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-performance
