2010/8/2 <david@xxxxxxx>: > On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: > >> 2010/8/2 <david@xxxxxxx>: >>> >>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote: >>> >>>> On Mon, Aug 2, 2010 at 5:08 PM, <david@xxxxxxx> wrote: >>>>> >>>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote: >>>>> >>>>> >>>>> you are close, but I think what I'm proposing is actually simpler >>>>> (assuming >>>>> that the scheduler can be configured to generate the appropriate stats) >>>>> >>>>> my thought was not to move applications between cgroups as they >>>>> aquire/release the suspend-block lock, bur rather to say that any >>>>> application that you would trust to get the suspend-block lock should >>>>> be >>>>> in >>>>> cgroup A while all other applications are in cgroup B >>>>> >>>>> when you are deciding if the system shoudl go to sleep because it is >>>>> idle, >>>>> ignore the activity of all applications in cgroup B >>>>> >>>>> if cgroup A applications are busy, the system is not idle and should >>>>> not >>>>> suspend. >>>>> >>>> >>>> Triggering suspend from idle has been suggested before. However, idle >>>> is not a signal that it is safe to suspend since timers stop in >>>> suspend (or the code could temporarily be waiting on a non-wakeup >>>> interrupt). If you add suspend blockers or wakelocks to prevent >>>> suspend while events you care about are pending, then it does not make >>>> a lot of sense to prevent suspend just because the cpu is not idle. >>> >>> isn't this a matter of making the suspend decision look at what timers >>> have >>> been set to expire in the near future and/or tweaking how long the system >>> needs to be idle before going to sleep? >>> >> >> You are describing low power idle modes, not suspend. Most timers stop >> in suspend, so a timer set 10 seconds from now when entering suspend >> will go off 10 seconds after resume so it should have no impact on how >> long you decide to stay in suspend. > > so what is the fundamental difference between deciding to go into low-power > idle modes to wake up back up on a given point in the future and deciding > that you are going to be idle for so long that you may as well suspend until > there is user input? > Low power idle modes are supposed to be transparent. Suspend stops the monotonic clock, ignores ready threads and switches over to a separate set of wakeup events/interrupts. We don't suspend until there is user input, we suspend until there is a wakeup event (user-input, incoming network data/phone-calls, alarms etc..). -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
