Re: DragonflyBSD kernel clock improvements

:I've ported PLL part (sys/i386/isa/clock.c change) and now I'm testing 
:it. I'll post the patch to this list once I will have finished. Right 
:now it works like  a charm, but I need to get rid of the constant skew 
:introduced in tvtohz().
:
:-Maxim

    Uh.  It really wasn't meant to be ported.  It was just some stopgap
    fun.  The real 'solution' to the inconsistent sleep() delays is to
    not use 'tick' granularity for nanosleep() for small timing intervals
    or tail-end timing intervals.

    What you really want to do is bring in the variable-delay hardware
    timer interrupt abstraction that's going to go into DFly in the next
    week or so, but that will be a lot harder without the IPI messaging
    infrastructure.  You'll have to wait, but I'll probably start posting
    test patches (for DFly) in one or two days once I get it working for
    SMP.

    Basically that abstraction will allow the kernel to 'register' multiple
    one-shot or periodic clock interrupt callbacks (with interrupt frame)
    on a per-cpu basis, which then in turn drives a variable load interrupt
    timer.  At the moment I am using Timer0 for that and getting the
    time base from Timer2 (disabling the speaker).  DFly is going to use this
    to 'register' periodic hardclock, statclock, and schedclock interrupts
    on a per-cpu basis.  The idea will eventually to be to use the LAPIC
    in SMP systems to provide per-cpu clock interrupts but that's at least
    a few months away for us.

    Then, with that in hand, it would be possible to 'fix' nanosleep() to
    actually do a fine-grained sleep for the requested time period.  A
    fine-grained nanosleep would be far more useful then a phase-synchronized
    tick timer.

    In anycase, watch for the patch sets.  I think the abstraction will be
    portable to 5.x but you you will need to also port the IPI messaging code
    (which is itself an extremely useful abstraction and well worth the
    porting effort, IMHO).

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>