Re: Attempted summary of suspend-blockers LKML thread

[david@lang.hm]

On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:

> On Saturday, August 07, 2010, david@lang.hm wrote:
>> On Sat, 7 Aug 2010, Mark Brown wrote:
>>
>>> On Fri, Aug 06, 2010 at 04:35:59PM -0700, david@lang.hm wrote:
>>>> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> ...
>> What we want to have happen in an ideal world is
>>
>> when the storage isn't needed (between reads) the storage should shutdown
>> to as low a power state as possible.
>>
>> when the CPU isn't needed (between decoding bursts) the CPU and as much of
>> the system as possible (potentially including some banks of RAM) should
>> shutdown to as low a power state as possible.
>
> Unfortunately, the criteria for "not being needed" are not really
> straightforward and one of the wakelocks' roles is to work around this issue.

if you can ignore the activity caused by the other "unimportant" processes 
in the system, why is this much different then just the one process 
running, in which case standard power management sleeps work pretty well.

>> today there are two ways of this happening, via the idle approach (on
>> everything except Android), or via suspend (on Android)
>>
>> Given that many platforms cannot go to into suspend while still playing
>> audio, the idle approach is not going to be able to be eliminated (and in
>> fact will be the most common approach to be used/deugged in terms of the
>> types of platforms), it seems to me that there may be a significant amount
>> of value in seeing if there is a way to change Android to use this
>> approach as well instead of having two different systems competing to do
>> the same job.
>
> There is a fundamental obstacle to that, though.  Namely, the Android
> developers say that the idle-based approach doesn't lead to sufficient energy
> savings due to periodic timers and "polling applications".

polling applications can be solved by deciding that they aren't going to 
be allowed to affect the power management decision (don't consider their 
CPU useage when deciding to go to sleep, don't consider their timers when 
deciding when to wake back up)

> Technically that
> boils down to the interrupt sources that remain active in the idle-based case
> and that are shut down during suspend.  If you found a way to deactivate all of
> them from the idle context in a non-racy fashion, that would probably satisfy
> the Android's needs too.

well, we already have similar capibility for other peripherals (I keep 
pointing to drive spin down as an example), the key to avoiding the 
races seems to be in the drivers supporting this.

the fact that Android is making it possible for suspend to selectivly 
avoid disabling them makes me think that a lot of the work needed to make 
this happen has probably been done. look at what would happen in a suspend 
if it decided to leave everything else on and just disable the one thing, 
that should e the same thing that happens if you are just disabling that 
one thing for idle sleep.

David Lang