On Fri, May 7, 2010 at 2:25 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Matthew Garrett <mjg@xxxxxxxxxx> [100507 13:58]: >> On Fri, May 07, 2010 at 01:53:29PM -0700, Tony Lindgren wrote: >> >> > So for example, if I leave ping running in a a terminal, do you >> > have some way of preventing that from eating the battery? >> >> It depends on policy. If all network packets generate wakeup events then >> no, that will carry on eating battery. If ICMP doesn't generate a wakeup >> event then the process won't be run. >> >> > Do you just suspend the whole system anyways at some point, >> > or do you have some other trick? >> >> If nothing's holding any suspend blocks then the system will enter >> suspend. If the packet generates a wakeup then the kernel would block >> suspend until userspace has had the opportunity to do so. Once userspace >> has handled the packet then it could release the block and the system >> will immediately transition back into suspend. > > OK, then what would I need to do to keep that ping running if I wanted to? > Use a suspend blocker. For instance: "runsuspendblock ping <addr>". >> Here's a different example. A process is waiting for a keypress, but >> because it's badly written it's also drawing to the screen at 60 frames >> per second and preventing the system from every going to idle. How do >> you quiesce the system while still ensuring that the keypress will be >> delivered to the application? > > I guess it depends. If it's a game and I'm waiting to hit the fire > button, then I don't want the system to suspend! > We don't suspend while the screen is on. If the user pressed the power button to turn the screen off, then I would not want the game to prevent suspend. > It's starting to sound like you're really using suspend blocks > to "certify" that the app is safe to keep running. > > Maybe it could be done with some kind of process flag instead that > would tell "this process is safe to keep running from timer point of view" > and if that flag is not set, then assume it's OK to stop the process > at any point? > > Regards, > > Tony > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
