Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras <felipe.contreras@gmail.com>]

On Fri, May 28, 2010 at 5:12 PM, Igor Stoppa <igor.stoppa@nokia.com> wrote:
> ext Brian Swetland wrote:
>> How is it flawed?  Serious question.
>
> I would avoid repeating all the good arguments given so far, but to make it
> short:
>
> * I believe runtime PM is a much better starting point (at least for the
> type of HW targeted at mobile devices) because it mimics an always-on system
> toward userspace, which requires less disruption in the way apps are
> designed

I agree.

If I understand correctly, if we have a perfect user-space that only
does work when strictly needed and trying to do it in bursts, then we
would be reaching the lowest power state, and there would be no need
for suspend. The problem is that Android's user-space is pretty far
from that, so they said "let's segregate user-space and go to lower
power mode anyway".

If that's true, then this problem can be fixed in user-space, and in
fact, it already is on N900. Good behaving applications are
asynchronous, use g_timeout_add_seconds() to align bursts of work at
the same second intervals, and don't do polls directly, but use GLib's
mainloop. Same as in GNOME desktop. It seems there are other methods
to align multiple processes for longer periods of time, but that code
is closed and I can't find much information.

> * QoS is closer to the apps pov: fps if it is a media player or a game,
> transfer speed if it is a file manager, bandwidth if it is a network app,
> etc
> The app is required to express its opinion by using a format that it
> understands better and is less system dependent.
> Actually the kernel should only be concerned with 2 parameters at most for
> any given operation: latency and bandwidth/throughput

I think this information can be obtained dynamically while the
application is running, and perhaps the limits can be stored. It would
be pretty difficult for the applications to give this kind of
information because there are so many variables.

For example, an media player can tell you: this clip has 24 fps, but
if the user is moving the time slider, the fps would increase and drop
very rapidly, and how much depends at least on the container format
and type of seek.

A game or a telephony app could tell you "I need real-time priority"
but so much as giving the details of latency and bandwidth? I find
that very unlikely.

Cheers.

-- 
Felipe Contreras