Re: device apic on a single processor machine

From: Mike Tancsa <mike_at_sentex.net>
Date: Wed, 27 Oct 2004 14:47:32 -0400
At 02:00 PM 27/10/2004, John Baldwin wrote:
>On Friday 22 October 2004 11:40 am, Mike Tancsa wrote:
> > When moving from RELENG_4 to RELENG_5, I noticed that in GENERIC, the
> > options
> >
> > options         SMP             # Symmetric MultiProcessor Kernel
> > device          apic            # I/O APIC
> >
> > are enabled by default.  Going forward, is this the best thing to leave in
> > my  default kernel on a uniprocessor machine ? I am not using the ULE
> > scheduler either and have hyperthreading disabled in the BIOS.
> >
> > I did a search on google, and in 2003 it was said not to having either on a
> > single processor machine but its not clear if this is no longer the case.
>
>You do want to drop SMP.  As far as 'apic', that is less clear.  If you have
>lots of PCI devices that share interrupts for the !apic case and you do lots
>of interrupt intensive tasks, then 'device apic' might help.  There may also
>be cases where it hurts.  There have been reports that access to the apic
>registers for things like masking sources takes longer than on the 8259As.


Thanks for the feedback. I guess my question is, what constitutes "lots" ? 
Typically, I strip down boxes to their bare min hardware wise so in most 
cases, I dont have anything sharing interrupts (I usually turn off USB 
which is the most gratuitous).  But I do have a POS app that needs USB as 
well as 2  PCI serial cards.  In this case, I do have a lot of shared 
interrupts.  However, it almost never is CPU bound or has an interrupt rate 
higher than 10-20%.  In this case, stability is more important to me.  I 
have run into a number of cases where there are interrupt storms (e.g 
http://lists.freebsd.org/pipermail/freebsd-current/2004-September/036967.html)

... So if it provides a cleaner / more stable way to talk to the devices, I 
will certainly run with it.

         ---Mike 
Received on Wed Oct 27 2004 - 16:40:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:19 UTC