Skip site navigation (1) Skip section navigation (2)

Re: noapic option

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: C Storm <christian(dot)storm(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: noapic option
Date: 2009-09-17 08:00:31
Message-ID: 1253174431.15147.53.camel@wallace.localnet (view raw or flat)
Thread:
Lists: pgsql-performance
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


In response to

Responses

pgsql-performance by date

Next:From: Richard HenwoodDate: 2009-09-17 12:55:07
Subject: optimizing for temporal data behind a view
Previous:From: Richard HuxtonDate: 2009-09-17 07:58:35
Subject: Re: Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group