| |||||||||||
Matthew Garrett on the race to idleMatthew Garrett on the race to idlePosted May 10, 2008 5:06 UTC (Sat) by dlang (subscriber, #313)In reply to: Matthew Garrett on the race to idle by mjg59 Parent article: Matthew Garrett on the race to idle
in theory you are right, in practice it doesn't work as well. take the OLPC laptop, designed for very good power management at the hardware level (with serious talk of going to sleep between keystrokes). due in large part to the need to have long enough delays to properly talk to things like external USB and SD devices this machine takes >200ms to wake up. yes there is defiantly room for improvement in the software, but the reliable interfacing to external (but effectivly permanently attached) devices is bad enough that doing race-to-idle ends up being a horrible thing in practice (they tried doing it in a few builds, it was bad enough that people started disabling sleep entirely)
(Log in to post comments)
Matthew Garrett on the race to idle Posted May 10, 2008 10:25 UTC (Sat) by mjg59 (subscriber, #23239) [Link] That's not race to idle, it's race to suspend. Linux is currently deficient in its requirement that the entire device tree be resumed before userspace can restart, which results in suckage like you describe. But that's an orthogonal issue - if you're talking about the processor rather than the platform, then the power saving states add only small levels of latency.
Matthew Garrett on the race to idle Posted May 10, 2008 10:37 UTC (Sat) by dlang (subscriber, #313) [Link] if you aren't switching to a suspend mode when you hit the idle state, what is the benifit of becoming idle? you can blame it on whatever layers you want, but for the user the result is the same, in practice the race-to-idle approach does not currently give a reasonable user experiance (in many cases), and as a result, switching to a lower clock speed instead of race-to-idle is actually better.
Matthew Garrett on the race to idle Posted May 10, 2008 10:53 UTC (Sat) by mjg59 (subscriber, #23239) [Link] The benefit is that your CPU power draw drops to approximately nothing. On modern CPUs, halving the speed of your processor doesn't halve its power draw. Letting it idle takes it down to 0-1 watts.
Matthew Garrett on the race to idle Posted May 11, 2008 11:23 UTC (Sun) by IkeTo (subscriber, #2122) [Link] > On modern CPUs, halving the speed of your processor doesn't halve its power draw. Hm... I read otherwise somewhere else, if you count only the power of the CPU. (Actually it should save more than half of its power, otherwise why slowing down?) Would you mind sharing with us where you get this idea?
Matthew Garrett on the race to idle Posted May 10, 2008 18:31 UTC (Sat) by dilinger (subscriber, #2867) [Link] Please do not use the OLPC laptop as an example. The power management software is not nearly close to being finished, and OLPC has suffered greatly from lack of manpower (I'll spare you the details of _why_ we haven't had enough people). In reality, there should be no reason why we can't do <200ms resume; however, no one within the organization has even _started_ optimizing away the extra 800ms that we deal with. The automatic suspend stuff that we had been toying with was merely a hack.
Matthew Garrett on the race to idle Posted May 11, 2008 14:44 UTC (Sun) by daniels (subscriber, #16193) [Link] I wouldn't call Geode/OLPC 'designed for good power management': it's lower power than most x86, sure, but isn't even in the same league as consumer device hardware like ARM and MIPS. If you can actually measure the wake-from-sleep time at all, then you've lost. Consumer hardware like the Nokia 770/N800/N810, OpenMoko, and similar, all races to sleep, and sleeps/resumes much, much more often than you think (probably by a factor of thousands). It really can be about as transparent as the x86 execution/idle switch if your hardware is decent, and you do it right. Current Linux on ARM definitely does it right. USB does make this more difficult by its very nature, but this isn't any more a problem with the concept of race-to-sleep than FireWire's remote DMA security fiasco is a problem with the concept of externally pluggable mass storage.
|
|||||||||||