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 Sun, May 3, 2009 at 1:42 AM, Matthew Dillon
> :It's not so simple. There is a problem when using deep sleep states in
> :modern CPU's (C3 and deeper) - lapic timer is stopped when CPU enters
> :into C3. And using C3 (or even C4) is obviously completely normal thing
> :to do in laptops.
> :See these commits for more pointers/details:
> :Hasso Tepper
> Hmm. The "lapic timer: Correct AMD C1E handling" commit doesn't
> fix that issue?
It is AMD only. AMD's multi-core CPU does not seem to be able enter
C2/C3 state, so AMD seem to invent C1E which is similar to C3.
> The cool thing about our systimers is that we do not use the
> systimer hardware itself to calculate elapsed time, we just use
> it as a one-shot. We use sys_cputimer (typically the ACPI or HPET)
> for elapsed time.
> This means the lapic timer *CAN* be temporarily disabled,
> just as long as some interrupt somewhere comes along at some
> point to wake the machine up, on every cpu that is in a sleep
> We would want to ensure that the sleep state is not held more then
> a millisecond or two, otherwise network polling and other very
> fast systimer events will not go as fast as expected. Slower
> systimer events such as the seconds timer and scheduler (100hz)
> are not as big an issue as long as the wakeup occurs in a
> reasonable period of time (aka < 10ms).
> If the lapic timer is disabled we clearly cannot depend on
> it to wake the machine up, so we might need some sort of
> fail-safe interrupt for that... maybe the 8254 can still
> be used for that purpose, or the RTC real time clock
> interrupt that we use for profiling. This interrupt would
> have to send a dummy IPI to every cpu on the system.
Switch one shot timer is quite simple now, since cputimer_intr_reload
is function pointer :)
Live Free or Die