[ale] Why APIC?

[Greg Freemyer]

On Thu, 9 Dec 2004 14:06:09 -0500, David Muse <david.muse at firstworks.com> wrote:
> On Thu, 9 Dec 2004 13:33:40 -0500
> 
> 
> Greg Freemyer <greg.freemyer at gmail.com> wrote:
> 
> > What is the advantage of APIC that it is typically enabled by default?
> >
> > I do a lot of disk i/o intensive work, and I had assumed that using
> > the APIC was a good thing for performance, but now I think I'm wrong.
> >
> > ===> Why I ask
> >
> > I have a machine based on an Intel P4 MB.
> >
> > I have used it regularly with SUSE 9.2 for at least a month.
> >
> > Yesterday it started complaining in /var/log/warn "Kernel: APIC error
> > on CPU0: 60(60)"
> >
> > Also the machine became unreliable and locked up a couple of times
> > (ie. unresponsive to the keyboard.)
> >
> > Based on a quick google search, one thing to try was "noapic" in the
> > grub entry.
> >
> > I've done that, and much to my surprise the disk i/o is even faster
> > than before.
> >
> > i.e. I just did a md5sum --check and per iostat I was reading 70,000
> > 512-byte blocks per second on 2 ide channels simultaneously.
> >
> > I don't remember ever getting more than 50,000 or so before.
> >
> > Even better, when one of the md5sum --check commands finished, the
> > other accelerated to 100,000 blocks per second.
> >
> > Thanks
> > Greg
> > --
> > Greg Freemyer
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
> >
> 
> I believe that an APIC is an interrupt router for multiple CPU's.
> 
> If a device says "hey, look at me!" then without an APIC, all CPU's
> would respond and then have to contend with each other for access to the
> device using spinlocks.  One CPU would ultimately handle the device and
> the others would go back to what they were doing before.  I believe an
> APIC handles interrupt contention in hardware so that only 1 CPU gets
> the interrupt.
> 
> On single CPU systems, I'm not sure why there'd even be an APIC, or if
> there is one, why you'd use it.  Maybe if your system supports multiple
> CPU's but you only have one plugged in or have the kernel compiled
> without SMP support, then you could either use the APIC or not.  Maybe
> some systems that support multiple CPU's require you to use the APIC
> even if only 1 CPU is plugged in or if your kernel is built without SMP
> support, so kernels are generally distributed with APIC support turned
> on so the kernel will work on those systems.
> 
> I'm not sure, but I suspect that if I/O performance is suffering with
> APIC support turned on, then it's either because your system has no APIC
> and the kernel has to deal with errors each time the IDE controller
> raises it's interrupt or because your system has an APIC which adds a
> little extra overhead each time an interrupt is processed, which would
> be fine on a multi-cpu machine because it's still better than
> spinlocking, but on a single-cpu machine, it just adds latency.
> 
> It may always be better to disable the APIC on a single CPU
> machine unless you know your system requires it to be enabled.
> 
> Dave Muse
> 
Thanks for the info.

I have a duiplicate machine of the first that I have now set to "noapic".

It too is running faster, unfortunately the first one is still locking up.

I guess it is time for memtest.

Greg