DragonFly commits List (threaded) for 2009-05
Re: DragonFly-184.108.40.2064.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
: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.