Hi! > > > Things that really *must* wake up periodically should be using some API that > > > interacts with RTC alarms, and those RTC alarms should be acting as system > > > wakeup events. > > > > But that means completely rewriting userspace. > > Completely? No. Hardly anything really _requires_ real-time wakeups. > > In any case, I can't possibly believe it's news to you that userspace code > which uses periodic polling is troublesome ... it wasn't news in the 1980s, > or 1990s, so it can't be news now. That's not just from the power management > perspective; it also makes trouble in GUI applications architecture > too. Well, maybe it is not news to _me_, but it is certainly news to application writers. Battery applet requires polling -- we have no battery interface that is event-driven, for example. Then you have clock on the desktop. Then there's blinking cursor (in X) at HZ/5 or something like that. How can kernel know which sleep is "important enough" to wake up system for it? Like, yes, we can probably do that on embedded platforms, but for something running KDE/Gnome? [Now, it is true that things are getting better. One of tricks is to make sure all the periodic polling happens synchronized (=> cpu can sleep for longer intervals between polls), and there are tricks like "only blink X cursor 5 times", but... try running timertop on KDE/Gnome system...] > > > There's also non-automated sleep too ... what "apmsleep" used to do when > > > you told it to suspend until 7am (or for two hours, etc). The same thing > > > can be done with /sys/power/state and a wakeup-enabled RTC. > > > > Yep, I should get it working one day. > > See the attached. "rtcwake -t $(( 5 * 60 * 60))" to sleep in standby mode > for five hours, or until some other wakeup event kicks in. :) Thanks. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
