DragonFly commits List (threaded) for 2009-05
Re: DragonFly-220.127.116.114.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
On Mon, May 4, 2009 at 12:00 AM, 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).
I will take a look at it.
> 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
Hoho, I think "ASAP" is best here. However, hasso's experience shows
the opposite :)
> 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
Yeah, I will try snoop systimer timeout value.
> 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.
Live Free or Die