2010/8/2 <david@xxxxxxx>:On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
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
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
cgroup A while all other applications are in cgroup B
when you are deciding if the system shoudl go to sleep because it is
ignore the activity of all applications in cgroup B
if cgroup A applications are busy, the system is not idle and should
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
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..).