DragonFly commits List (threaded) for 2009-05
DragonFly BSD
DragonFly commits List (threaded) for 2009-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 2 May 2009 10:42:10 -0700 (PDT)

: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:
:
:http://permalink.gmane.org/gmane.os.freebsd.devel.cvs.src/105079
:http://lists.xensource.com/archives/html/xen-changelog/2008-05/msg00221.html
:http://bugzilla.kernel.org/show_bug.cgi?id=2560
:
:-- 
:Hasso Tepper

    Hmm.  The "lapic timer: Correct AMD C1E handling" commit doesn't
    fix that issue?

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

    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.

    Does the ACPI code itself have some sort of sleep timeout
    that can be set?  If so we can use that to do the required
    wakeup.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]