> > By design, autosuspends should not change the timing behavior of programs; > > the idea is for the computer to act the same, but do so using less power. > > Autosuspend and lid-close suspends are identical in function. The only > difference is the allowed wakeup source. The CPU is turned off. All > timing save the RTC (and EC [1]) is stopped.
These two suspends are only identical in function in the EC. They need not be identical in the kernel. > With the RTC you have a 1 second ambiguity There is no 1-second ambiguity in the RTC. The CPU can only read out a value accurate to 1 second, but the CPU can tell precisely when the RTC "ticks" from one second to another, which gives it much higher precision if it's willing to wait. Its precision is greater than its accuracy. As "man 8 hwclock" says, "The control program can read or set this clock to a whole second, but the control program can also detect the edges of the 1 second clock ticks, so the clock actually has virtually infinite precision." See also the discussion in the initial comments in hwclock.c: http://www.sfr-fresh.com/linux/misc/hwclock-2.32.tgz:a/hwclock-2.32/hwclock.c > and the timing precision of the EC is not suitable for > accuracy over longer periods or temperature changes. (its RC based) If it's within 10% or 20%, the EC's resistor-capacitor based timing is accurate enough for the kernel's purposes in doing short suspends of the CPU invisibly. It's unlikely that the kernel will decide to suspend for more than an hour, say; probably some daemon or kernel code will be scheduled to wake up before then. (The invisible suspend code can set an upper limit and force a wakeup every 10 minutes, for example, if it thinks that's prudent.) The kernel can initially err on the side of waking early. After each resume, it can accurately measure the inaccuracy of the RC-based timer on that suspend. Then it can improve its estimates to let it the next suspend wake later and thus waste less power. Of course it will always need to keep waking early enough that a temperature change that alters the timer's inaccuracy won't make it miss a deadline, but for the expected short sleeps of under a minute, there isn't much time for the temperature to change while suspended, even if the laptop moves from sun to shade or vice verse during that minute. The kernel in XO-1 has at least two ways to accurately measure the duration of an EC timer based suspend. One is to use the CPU clock to count subseconds since power-up, and then watch for an RTC clock tick. When the RTC ticks, subtract the subsecond count from the CPU clock, and you'll know exactly when the CPU resumed. A second way is to leave an MFGPT timer running during suspend. There are one or two timers that can't wake the system, but which can count while suspended, and at high accuracy. See http://dev.laptop.org/ticket/6053#comment:7 and subsequent comments. I haven't examined the XO-1.5 timer situation. > So with the system as it stands there is really no (good) way to > accomplish a zero timing impact suspend. There are clever ways to do it despite the limitations of the hardware. When the CPU restarts after a suspend, the kernel can decide how to treat sleeping processes. In a suspend that's intended to be invisible, the kernel already knows it asked to be powered down for a shorter time than any pending userspace sleep() call or kernel timer queue entry. The kernel can figure out how long the suspend actually was, to high precision, and can then awaken the user process or kernel task at the proper time. A lot of this is explored in http://dev.laptop.org/ticket/6053 (Clock drift during suspend/resume), http://dev.laptop.org/ticket/4606 (XO can't resume from suspend at a particular time set by software), and http://dev.laptop.org/ticket/3359#comment:3 . These are 3-year-old bugs, so it's unsurprising if you've forgotten their contents, but since I did a lot of the analysis of how we COULD do invisible suspends, I remembered where to look for the details. John PS: Invisible suspends will work much better if you fix #9054 as well, pulling 700ms out of the resume path and making it effective to suspend the system even if it needs to reawaken a few seconds later. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
