systimer02.patch available for review.

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    systimer02.patch is now available:

	http://apollo.backplane.com/DFlyMisc/systimer02.patch

    This patch should work properly with SMP and also makes nanosleep()
    fine-grained.  There are still some overhead issues in nanosleep. 
    Basically it works like this:

	nanosleep1(...)
	{
	    while (not done) {
		if (us < kern.sleep_hard_us) {
		    uio_yield();	/* hard loop in yield */
		} else if (us < one_hz_tick) {
		    block with a systimer-based oneshot
		} else {
		    block using tsleep
		}
	    }
	}

    kern.sleep_hard_us defaults to 100, meaning that nanosleep will hard
    loop in yield for requests of less then 100uS.  The overhead seems to
    be around 4uS.  For sleeps of less then one tick, nanosleep uses a
    systimer-based one shot.  This introduces significant interrupt
    and other overheads and the resulting nanosleep will run about 33uS
    longer.  Finally, for long sleeps nanosleep will use tsleep() for the
    course portion of the sleep, and uio_yield() for the fine portion.

    Also, nanosleep is using an uncompensated time calculation so the longer
    you sleep, the greater the drift relative to realtime.  

    More work could be done but this is good enough for now.

    I did some SMP cleanup work, including synchronizing the periodic
    interrupts running on each cpu with cpu 0 so the actual hardware
    interrupt can process several timeouts at once.

    The realtime clock interrupt (128Hz which drove the statclock) is no
    longer used.  The stat clock is being driven via systimers and thus
    is 8254Timer0 based.

    This infrastructure gives us a nice jumping off point for future work,
    such as using per-cpu APIC timer interrupts.  Systimers also work outside
    of the MP lock, which is an important step.  We can get away with this
    for statclock and hardclock because most they work on the 'current
    process' (on any given cpu) most of the time.  I changed a bunched of
    splclock()'s to crit_enter()/crit_exit() to properly interlock against
    the new hardclock and statclock code since it can be entered from an IPI
    interrupt rather then the actual hardware timer interrupt.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>