DragonFly-2.3.0.864.gc5b83 master sys/platform/pc32/apic mpapic.c sys/platform/pc32/isa clock.c sys/platform/pc64/isa clock.c sys/platform/vkernel/platform systimer.c sys/sys systimer.h

[Matthew Dillon]

:I am thinking about it too.  However, I am more interested in per-cpu
:rate instead of the total rate (I am not saying total rate is not
:useful :).  So how about add another systat item?  I would like it to
:show per-cpu lapic timer rate and possibly ipi rate.

    V_INTR is per-cpu already.  We could add a V_IPI field for Xipiq
    interrupts.  We could also add a separate V_TIMER as well and have systat
    report it independantly of the normal interrupt list.

    systat currently aggregates them (or the kernel does when you do the
    sysctl to report the vmstats, I forget).

    --

    Are you sure you want to call i8254_intr_reload(0) in
    cputimer_intr_switch() ?  Won't that generate an almost immediate
    interrupt?  I figure we might want to just unconditionally set it
    to e.g. 1ms (TIMER_FREQ / 1000), or a better way: Any cpu entering
    the sleep state can snoop the next systimer timeout and actually
    pass the correct value to it.

    I have an even better idea.  We don't have to switch timers for C3/C1E,
    there is no reason why BOTH couldn't call into the same systimer
    infrastructure. I'd prefer a new API function block for sleep-state
    interrupt queueing, e.g.  (cputimer_intr_sleep_reload).
    (cputimer_intr_reload could) then be permanently set to the LAPIC
    (though keep the sysctl logic to switch it), and
    (cputimer_intr_sleep_reload) could be permanently set to the 8254.

    Then on entry to C3/C1E the ACPI code could explicitly call
    cputimer_intr_sleep_reload(), and on exit it could explicitly
    resynchronize the LAPIC like it does already (I think).

    We can thus leave the LAPIC timer interrupt logic alone when going into
    and out of the deep sleep state.  i.e. a double interrupt is ok if
    the LAPIC timer happens to not get disabled by the ACPI logic.
    That would make the API a lot cleaner.

					-Matt