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

quoted text
> 2010/8/2  <david@lang.hm>:
>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> On Mon, Aug 2, 2010 at 5:08 PM,  <david@lang.hm> 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?

David Lang