Re: Attempted summary of suspend-blockers LKML thread

2010/8/2  [off-list ref]:

On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:

quoted

On Mon, Aug 2, 2010 at 5:08 PM,  [off-list ref] wrote:

quoted

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.

to properly do a good job at suspending hyperagressivly you need to look at
when you need to wake back up (after all, if you are only going to sleep for
1 second, it makes no sense to try and enter a sleep state that takes .5
seconds to get into and .6 seconds to get out of, you need to pick a lighter
power saving mode)

if you really want to have the application be able to say 'I am ready for
you to go to sleep NOW and I don't want any chance of waking back up until
the system is ready for me to do so' it may be possible to have a special
dev file that when a program attempts to read from it the program is
considered to have been idle forever (expiring any 'delay since last
activity' timers that are running for that process) and when the device
wakes back up (or after a little bit of time if the device decides not to go
back to sleep), allow the return from the blocking call to allow the app to
continue running.

but I am not sure that something like that is needed. I think just checking
for timers that are due to expire 'soon' and tweaking how long the system
must be 'idle' before it decides to go to sleep should be good enough.

David Lang

-- 
Arve Hjønnevåg