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

[Sepherosa Ziehau]

On Mon, May 4, 2009 at 12:00 AM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
> :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.

OK

>
>    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

Implicitly?

>    resynchronize the LAPIC like it does already (I think).

Sounds good.

>
>    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.

Yeah.

Best Regards,
sephe

-- 
Live Free or Die