> The problem with the pure hereustic approach is that there may > be times when we don't have enough knowledge about the system state > and more importantly the user's behaviour to really make a decision > without information from the application. For example, if I am streaming > music on my computer, and I walk away for sometime, it may be perfectly > OK to go to do a full suspend, or it maybe the case that I don't want to > go to sleep but it's OK for me to shutdown the screen. Simply looking at > what is the current process doing (using network and audio resources) is > not enough to make a smart judgement on what to do in this situation. > There must be a way for the user to tell the application what to do > and a way for the application to pass that information into the system > power manager.
There are already a couple of knobs for users to tweak their power-control desires with (in the Sugar control panel). We could add a few more (though this makes more combinations to test, and to explain, and that will break some things for some users). User controls are orthogonal to whether "Activities" request a suspend or no suspending, which was the suggestion I was dissing. > > We should understand why ohm isn't noticing that the activity updater > > isn't idle. Should Ohm be looking for a higher cpu idle% in the > > seconds before it suspends? Should it be looking for minimal numbers > > of context switches per second before it suspends? ... > > What happens when the updater is modified? Do we have to reanalyze > the behaviour pattern everyime we have chage the updater and then rewrite > the heurestic code in OHM? What if I'm doing something else at the > same time as running the updater which completely modifies the behaviour? > And what about when we change to a new kernel and the scheduler behaviour > changes (see #7603)? For an idea of where Linux power management is going, see Richard Woodruff's presentation from the Ottawa Linux Power Management summit: http://www.celinux.org/elc08_presentations/TI_OMAP3430_Linux_PM_reference.ppt http://article.gmane.org/gmane.linux.acpi.devel/33176 What OLPC is doing was cutting-edge -- before Richard got started. And he's not putting kludges into applications -- he's hacking how the kernel allocates resources (which is its job and its only job). His code is in mainline kernels, runs on the Texas Instruments OMAP3 system-on-chip, and aims for cellphone-like battery life with Linux-laptop-like features and performance. (I have no inside knowledge, but would be surprised if the OMAP3 wasn't a possible candidate processor for the XO-2.) My favorite slide is #3, the graph of volts and amps -- which sits at zero volts, zero amps most of the time, and rises to 0.9 volts at 50 mA occasionally, spending 94% of its time at zero. This is running Linux on a 550 MHz ARM. In Richard's model, drivers clock down and/or power down their devices whenever they aren't in use, and can rapidly power them up and restore their registers as needed, invisibly to user software. This includes the "CPU driver", i.e. the scheduler, dispatcher, and cpuidle implementation. The CPU goes through 7 increasingly power-miserly states, resuming from the deepest (CPU power-off) in about 30ms. The reason the XO-1 has had so much trouble with suspend is because it's a first-generation effort, using a processor that was designed for Winblows' multi-second manual suspends. Our board design also took a lot of evolution and still has a few misfeatures. Things will be very different in the hardware world shortly. OLPC gets significant credit for pushing the chip industry to notice how badly its power management sucked. Let's not mess up our code base (or our mindsets) while they're going through the design cycles to get it right. (The XO-1 hardware can do much better than it's doing. I see in Joyride-2263 that USB drivers are in modules now, so Ohm can unload 'em when it wants to suspend and resume in only HALF a second instead of a whole second. But when I enable "Extreme Power Management", ohm is not actually powering off the USB bus and unloading the USB modules yet! My USB keyboard works if plugged in; and the modules are still there. Chris, does this need a new TRAC besides #7113 and #7434?) John _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
