Re: Side note on Shuttle XPC / AMD X2 (SN95G5V3) (Re: [PATCH] nve(4) locking cleanup)

:We've punted on using IRQ0 with lapic's altogether and use the lapic timer now 
:to drive hardclock, statclock, and profclock.  Not only do some motherboards 
:not hook up IRQ0 to intpin 2 on the first I/O APIC requiring the use of mixed 
:mode to route IRQ0 on such boards, but on some recent systems such as the 
:Compaq R3000z amd64 laptops it seems that instead of pin 0 on the first I/O 
:APIC being an ExtINT pin, it is actually IRQ0 and there is no ExtINT pin (and 
:pin 2 on the first I/O APIC isn't hooked up to anything).  I think IRQ0 with 
:APICs is only going to get worse and worse as time goes on.

    I'll probably be adding support for the LAPIC timer for APIC_IO builds
    after our next release.   It hasn't been a priority because the current
    8254 code, while crufty, is at least bug free.  Since we do not have to
    access any hardware timers in the critical context switching path (I
    think FreeBSD still does that), access latency is not really an issue.
    8254 interrupt routing is clearly becoming an issue so it will be a
    nice refreshing change to not have to deal with it.

    We have a SYSTIMER abstraction which is used for all high frequency
    one-shot and periodic events in the system.  The SYSTIMER code is already
    100% MPSAFE, cpu-localized, and designed to be able to use the LAPIC
    on each cpu, so it is really just a matter of actually wiring the
    LAPIC timers up to it.  Since we can use the LAPIC with ICU (8259)
    interrupt routing we'll be able to use the LAPIC timer on all systems
    that have an LAPIC no matter the build.  Most of DragonFly's periodic
    operations are no longer related to 'hz' in any way.  So, e.g. the
    frequency for network polling, scheduling, statistics, profiling,
    interrupt rate limiting, emergency interrupt polling, etc, can all be
    set independantly of each other and some have even been wired into
    sysctl's so they can be changed on the fly.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>