> > just fix the kernel so the suspend > > ends when the next process wants to run. > > Have a look at powertop -- you'll never suspend, there are several > hundred wakeups per second.
Did we give up on fixing these? (I don't have an XO-1.5 so I can't see its powertop results.) > If you want to do better than super-idling the way that recent kernels > do, you have to get into the "suspend transparently and aggressively" > game, like modern mobile phones do. I don't think I want my computers to become as stupid as my phones. Programs don't have to busy-wait. We defined kernel interfaces for programs to wait for things to happen, decades ago. We've evolved them as needed. When a clueless program maxes out the CPU by busy-waiting, historically it gets patched or fixed so that it does a kernel call that makes it sleep when there's nothing to do -- and lets the kernel know what event should wake it up. As far as I can tell, that paradigm has not failed us. We just need to move from fixing the programs that burn 100% of the CPU when idle, to fixing the programs that wake up dozens of times a second when idle. Replacing that with a new model of "transparent and aggressive" suspends (that are not transparent to user programs) is a problem, not a solution. I detected a wakeup bug in the Python interpreter three years ago. After some nudging, Guido made a Python interpreter patch, letting signals be transmitted via a file descriptor, preventing it from doing 10 useless wakeups/sec in case a signal might have arrived. Then the libraries needed to be patched to use the new interface. The whole integrated fix is *still* not in production, as far as I can tell: Sugar apps' pygtk main loop polls 10 times a second, always http://dev.laptop.org/ticket/4680 Patch for signal.set_wakeup_fd http://bugs.python.org/issue1583 python-2.5.2-set_wakeup_fd4.patch is not what went upstream https://bugzilla.redhat.com/show_bug.cgi?id=475005 Calling gobject.threads_init() causes a lot of wakeups (PyGObject) https://bugzilla.gnome.org/show_bug.cgi?id=481569 Calling gobject.threads_init() causes a lot of wakeups (PyGTK) https://bugzilla.gnome.org/show_bug.cgi?id=611050 Perhaps these fixes have made it into F12? Are all our multitasked Python programs waking up 10x/sec now, or not? If they are still waking up 10x per second, let's fix this bug. (If it's fixed, let's close those tickets.) Let's not introduce some new API so the kernel can tell the difference between when they really *mean* to wake up, versus when they are just waking up because they don't know any better. > It is a pain -- some cases can be handled transparently, others need a > bit of work in making the apps suspend-aware. But the payoff is huge. The huge payoff you mention is that you can brute-force "aggressive suspend with numerous bugs" into a product and improve one release of one product's battery life. But portable apps won't run well on your product, because there's no real reason for your extra API. And you'll have bugs from Day 1 to Kingdom Come, because you broke the cleanly defined interface between the kernel and the user programs. (This set of bugs is why we never shipped with aggressive suspend enabled on the XO-1. Let me guess, the now-smaller XO software support org has decided it can live with this level of bugs, so has reversed that decision. Now "the XO-1.5 uses less power than the XO-1", but of course the XO-1 would use less power if you turned on "agressive and intrusive" suspends there too.) A cleanly defined kernel interface doesn't require "making apps suspend-aware". Aggressive suspend is just doing it clumsily because we had no time to do it right. John _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
