Re: Attempted summary of suspend-blockers LKML thread, take three

[Ted Ts'o]

On Sun, Aug 08, 2010 at 03:53:52PM +0300, Felipe Contreras wrote:
> 
> You are overgeneralizing; there are many applications that run in the
> background, and you want to keep them running even when the display is
> off.

Really?  How many do you really expect will be running at the same
time on a mobile platform with a 800-1000 mWh battery?  And what
percentage of the applications that might be in a Android or Moblin or
Maemo app store will have things running in the background?  10%?
20%?  50%?  80%?

> You seen to be concentrating on UI-only applications, for those it's
> worth noting that Android provides separate mechanisms for power
> saving. Since Android doesn't have true multi-tasking, the
> applications must serialize their states so that the next time they
> are opened they seem to have not been closed. So, the current active
> UI application can be closed while turning off the display, and
> re-opened later.

Actually in practice, the process or processes which comprise current
active UI application generally won't actually be killed when you turn
off the display.  It *might* happen, if one of the rare backround
applications needs more memory than is available without closing some
of the more recently open applications.  In practice, the last 2-3
most recently used applications are still loaded in memory so you can
switch back and forth between them simply and easily.  It is true they
have to be ready to be killed at any time in case their memory is
needed for the currently active application, but that generally does't
happen right away.  The design is to keep this transparent to the user
so the user does't have to keep track of how many apps currently
running on the system.

In any case, the key thing to keep in mind is that when you deal with
extreme power savings, very often you end up making compromises that
probably make sense for other reasons anyway (such as the small screen
size).  It's not at all clear that supporting generalized
multi-tasking applications makes sense just from a screen real-estate
issue and user experience POV, never mind battery lifetime.

> User-space suspend blockers are relevant for background services, and
> as it has been discussed before; suspend blockers (not activating
> them) might actually degrade power usage.

Yes, absolutely.  Note though that with the iPhone, Apple has decided
that the only background services that will be allowed is audio, VOIP,
location/navigation, and push notifications.  iOS developers don't get
access to anything else, and the argument is that nothing else is
really *needed*.  Android is more flexible in that it allows for
non-Apple developers to create new background services, but it's not
clear how many you really *need*.

This goes back to your first assertion that there are *many*
applications that need to run in the background.  I just don't think
that's true.  There will be a few, and probably more than just the
restricted set allowed (and programmed) by Apple.  But not *many*.

						- Ted

P.S.  Although you won't see Apple admitting it, their "fast app
switching" is basically what Android has had all along, and most
mobile developers are quite happy to call this multi-tasking.  Yes,
it's not the same as trying to compile the kernel using "make -j 16"
in the background.  But are you really going to do that on a cell
phone battery?  I think not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/