Re: [RFC][PATCH 0/9] Suspend block api (version 3)

[Kevin Hilman <khilman@deeprootsystems.com>]

Arve Hjønnevåg <arve@android.com> writes:

> 2009/5/6 Kevin Hilman <khilman@deeprootsystems.com>:
>> Arve Hjønnevåg <arve@android.com> writes:
>>
>>> This patch series adds a suspend-block api that provides the same
>>> functionality as the android wakelock api. This patch series removes
>>> the sysdev that was used to abort suspend and adds a direct check in
>>> suspend_enter instead. It also has some other code style changes.
>>
>> Sorry for joining the wakelock/suspend-block discussion a bit late,
>> but I have a very basic, and possibly stupid question on the need for
>> such a feature.
>>
>> My basic question: is why not use idle (dynamic PM) instead of suspend
>> (static PM) for this?
>>
>
> We use suspend in addition to idle, not instead of. On some systems
> (msm) we can enter the same power state from idle as from suspend.
> This reduces the importance of suspend, but entering suspend still has
> benefits. The monotonic clock stops and all the periodic timers
> (user-space and kernel) that are based on it stop with it. It also
> reduces the amount of energy an untrusted application can waste since
> it will not be allowed to run when the system is suspended.
>
>> IOW, why not use CPUidle + PM QoS to achieve the same goal?  It seems
>> to me that you're trying to add some dynamic PM features onto a static
>> PM subsystem.  I could see PM QoS possibly needing some extending but
>> the basic abilities to constrain the low-power states are there.
>
> suspend blockers have no impact on this.
>
>> The one reason I can think of is that you can always have broken
>> drivers or apps that prevent you from hitting idle.  But with tools
>> like powertop, it's pretty easy to find these problems and fix them.
>>
> Tools allow you to find apps that waste power, but they do not fix them.
>
>> If that is the primary concern, it seems to me that we're introducing
>> a new kernel API to work around broken drivers and apps that should be
>> fixed instead.
>>
>> What am I missing?
>
> Suspend blockers allow you to use suspend. On platforms that cannot
> enter the same power state from idle this is essential. On platforms
> can enter the same power state from idle as suspend, suspend reduce
> the time spent running which in turn reduces the overall power draw.
> It also offers some protection against bad apps which is important on
> an open device.

Arve,

Thanks for the clarifications.  Like Mark, I feel like I have a better
grip on the motivation behind these changes.

Thanks,

Kevin