Re: noapic option

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