Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Maemo: Developers

suspendprocess - poor man's power save

 

 

Maemo developers RSS feed   Index | Next | Previous | View Threaded


maemo at csipa

Sep 12, 2010, 1:47 AM

Post #1 of 14 (969 views)
Permalink
suspendprocess - poor man's power save

It has been difficult for many developers to comply with many of the recommended
power-saving practices for Maemo, especially those porting apps from desktop
environments. I'm not sure how many of you noticed already, but in the best
hack-tradition of the N900 mikkov made a suspendprocess package, not unlike
what was talked about on this list - which could allow many of these power-
guzzling apps to become a little more suspend-power-friendly with little to no
effort.

http://maemo.org/packages/package_instance/view/fremantle_extras-
devel_free_armel/suspendprocess/0.1/

Basically it is a launch-wrapper that SIGSTOPs and resumes the app it started
based on the DBUS signals.

I would recommend all interested parties to take a look and if it
improves/helps in their apps/packages, apply it to them (or report any
problems/improvement suggestions, naturally). It's not the prettiest solution
and native level DBUS solution is of course still preferred by far, but if you
don't have that time or luxury (or are blessed with SDL code or similar), this
might come handy.


Best regards,
Attila Csipa
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


vivainio at gmail

Sep 18, 2010, 8:20 PM

Post #2 of 14 (949 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Sun, Sep 12, 2010 at 9:47 AM, Attila Csipa <maemo [at] csipa> wrote:

> It has been difficult for many developers to comply with many of the recommended
> power-saving practices for Maemo, especially those porting apps from desktop
> environments. I'm not sure how many of you noticed already, but in the best
> hack-tradition of the N900 mikkov made a suspendprocess package, not unlike
> what was talked about on this list - which could allow many of these power-
> guzzling apps to become a little more suspend-power-friendly with little to no
> effort.
>
> http://maemo.org/packages/package_instance/view/fremantle_extras-
> devel_free_armel/suspendprocess/0.1/
>
> Basically it is a launch-wrapper that SIGSTOPs and resumes the app it started
> based on the DBUS signals.
>
> I would recommend all interested parties to take a look and if it
> improves/helps in their apps/packages, apply it to them (or report any
> problems/improvement suggestions, naturally). It's not the prettiest solution
> and native level DBUS solution is of course still preferred by far, but if you
> don't have that time or luxury (or are blessed with SDL code or similar), this
> might come handy.


Quoting everything because this is an old email (and not everyone
still has it around).

It's an intriguing hack, and I'm somewhat curious about people's
thoughts about the following:

1) Will native dbus solution *really* be better in all cases? Or would
suspending the process actually help move a sleeping process to swap
more aggressively than just blocking?

2) Perhaps this would be even more useful to keep multitasking memory
usage at bay - by suspending the processes not in foreground (by their
own volition of course)?

3) It seems to be implemented in python + somewhat heavy libs
(gobject, osso). C + libdbus implementation would be more convenient,
esp. if this turns out to be a popular approach.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


vivainio at gmail

Sep 18, 2010, 10:20 PM

Post #3 of 14 (946 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Sun, Sep 19, 2010 at 9:27 AM, Ville M. Vainio <vivainio [at] gmail> wrote:

> 2) Perhaps this would be even more useful to keep multitasking memory
> usage at bay - by suspending the processes not in foreground (by their
> own volition of course)?

... one more thought:

It would be more useful if it wasn't a launch wrapper, but rather a
lone daemon that sits in the background and suspends a set of
processes according to given heuristics (e.g. suspend gpodder when a
call is initiated, matched by /proc/NNN/cmdline).

This would allow suspend rules to be created for apps outside the
packaging/implementation for the app itself.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


viroteck at viroteck

Sep 19, 2010, 9:58 AM

Post #4 of 14 (946 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

Hi,

Excerpts from Ville M. Vainio's message of Sun Sep 19 09:27:43 +0100 2010:
> 2) Perhaps this would be even more useful to keep multitasking memory
> usage at bay - by suspending the processes not in foreground (by their
> own volition of course)?

I started writing a reply to this ages ago, but time kind of sapped it up and so
I never finished.

Anyway: this was pretty much in keeping with my idea: move it into the task
switcher (hildon-desktop/other) so that applications which are moved to
background are stopped (unless they signal for whatever reason that they
need to be kept running, but I'm not even sure that is necessary: if
you really need to do background processing constantly, why do it in a
GUI application?)

This might raise minor inconvenience for application developers that _do_
genuinely need to run something constantly, but it would make life a lot easier
for the end-user if it did provide a good boost for battery.

--
Robin Burchell
http://rburchell.com
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


andrew at bleb

Sep 19, 2010, 10:36 AM

Post #5 of 14 (942 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Sun, Sep 19, 2010 at 17:58, Robin Burchell <viroteck [at] viroteck> wrote:
>
> Anyway: this was pretty much in keeping with my idea: move it into the task
> switcher (hildon-desktop/other) so that applications which are moved to
> background are stopped (unless they signal for whatever reason that they
> need to be kept running, but I'm not even sure that is necessary: if
> you really need to do background processing constantly, why do it in a
> GUI application?)

I suggested something similar three years ago (wow, Maemo's old ;-))
and the reaction was less favourable:

http://www.gossamer-threads.com/lists/maemo/users/26337

For example, Igor Stoppa wrote:
>
> You are proposing a shortcut that is encouraging crappy code to be
> written, since the system will always take care of saying: "psst,
> pretend to be a properly written piece of code".
>
> If an application has nothing to do, it _must_ be blocked waiting for
> something, such as an event, a timer, whatever it cares about, nothing
> else.

Personally, I think it'd still be useful; without going to the
(almost) co-operative multi-tasking of iOS.

Cheers,

Andrew

--
Andrew Flegg -- mailto:andrew [at] bleb | http://www.bleb.org/
Maemo Community Council chair
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


anidel at gmail

Sep 19, 2010, 7:24 PM

Post #6 of 14 (942 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

----- Original message -----
> On Sun, Sep 19, 2010 at 17:58, Robin Burchell <viroteck [at] viroteck>
> wrote:
> >
> > Anyway: this was pretty much in keeping with my idea: move it into the
> > task switcher (hildon-desktop/other) so that applications which are
> > moved to background are stopped (unless they signal for whatever
> > reason that they need to be kept running, but I'm not even sure that
> > is necessary: if you really need to do background processing
> > constantly, why do it in a GUI application?)
>
> I suggested something similar three years ago (wow, Maemo's old ;-))
> and the reaction was less favourable:
>
>        http://www.gossamer-threads.com/lists/maemo/users/26337
>
> For example, Igor Stoppa wrote:
> >
> > You are proposing a shortcut that is encouraging crappy code to be
> > written, since the system will always take care of saying: "psst,
> > pretend to be a properly written piece of code".
> >
> > If an application has nothing to do, it _must_ be blocked waiting for
> > something, such as an event, a timer, whatever it cares about, nothing
> > else.
>
> Personally, I think it'd still be useful; without going to the
> (almost) co-operative multi-tasking of iOS.
>
> Cheers,
>
> Andrew
>

I'd agree with Igor if the application is a newly written one.

But when porting from desktop to Maemo, adapting the code to be less power hungry can be a daunting task and not many developers have time for it (let's not forget that many port apps to Maemo for fun or bacause they need the port... it is, indeed, a hobby)

So I'd favour such an approach as well.

Aniello
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


maemo at csipa

Sep 20, 2010, 2:08 AM

Post #7 of 14 (937 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Sun, Sep 19, 2010 at 7:58 PM, Robin Burchell <viroteck [at] viroteck>wrote:

>
> Anyway: this was pretty much in keeping with my idea: move it into the task
> switcher (hildon-desktop/other) so that applications which are moved to
> background are stopped (unless they signal for whatever reason that they
> need to be kept running, but I'm not even sure that is necessary: if
> you really need to do background processing constantly, why do it in a
> GUI application?)
>

Hey, continue down that path and you'll be in iOS style cooperative-daemon
multitasking in no-time :) Which, while not bad in itself, DOES require a
substantial level of effort on part of the developer, especially, as
mentioned by others, if it's a port using funky event loops. That's why,
unlike in the case of iOS I do believe this call is not to be made by
*compulsorily* overcomplicated by the OS/daemons in our case.


On Sun, Sep 19, 2010 at 1:42 PM, Ville M. Vainio <vivainio [at] gmail> wrote:

> It would be more useful if it wasn't a launch wrapper, but rather a
> lone daemon that sits in the background and suspends a set of
> processes according to given heuristics (e.g. suspend gpodder when a
> call is initiated, matched by /proc/NNN/cmdline).
>
> This would allow suspend rules to be created for apps outside the
> packaging/implementation for the app itself.


I kinda would say this fits Shepherd's use-case (DBUS suspend/resume event
as trigger, SIGSTOP/resume as action), but considering how late I am on that
project I better keep quiet :)



Best regards,
Attila


eero.tamminen at nokia

Sep 20, 2010, 7:35 AM

Post #8 of 14 (934 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

Hi,

ext Andrew Flegg wrote:
> On Sun, Sep 19, 2010 at 17:58, Robin Burchell <viroteck [at] viroteck> wrote:
>> Anyway: this was pretty much in keeping with my idea: move it into the task
>> switcher (hildon-desktop/other) so that applications which are moved to
>> background are stopped (unless they signal for whatever reason that they
>> need to be kept running, but I'm not even sure that is necessary: if
>> you really need to do background processing constantly, why do it in a
>> GUI application?)
>
> I suggested something similar three years ago (wow, Maemo's old ;-))
> and the reaction was less favourable:
>
> http://www.gossamer-threads.com/lists/maemo/users/26337
>
> For example, Igor Stoppa wrote:
>> You are proposing a shortcut that is encouraging crappy code to be
>> written, since the system will always take care of saying: "psst,
>> pretend to be a properly written piece of code".
>>
>> If an application has nothing to do, it _must_ be blocked waiting for
>> something, such as an event, a timer, whatever it cares about, nothing
>> else.
>
> Personally, I think it'd still be useful; without going to the
> (almost) co-operative multi-tasking of iOS.

There are some potential downsides for just suspending processes
completely. Most of the processes have subscribed to several
different D-BUS messages, X events etc.

For example D-BUS will infinitely buffer messages that are sent
to a connected client but not read by it. If these messages can
be very frequent (say device orientation & network condition messages),
this will soon bloat D-BUS memory usage quite a bit. After D-BUS
starts to swap, it won't perform very well.

These kind of services cannot be restarted without restarting the whole
device (as all connected clients would exit), so there's no easy fix for
that effect either, like there's for example for a leaky in-process
3rd party Home applet (restarting Home).


- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


vivainio at gmail

Sep 20, 2010, 1:20 PM

Post #9 of 14 (941 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Mon, Sep 20, 2010 at 3:35 PM, Eero Tamminen <eero.tamminen [at] nokia> wrote:

> For example D-BUS will infinitely buffer messages that are sent
> to a connected client but not read by it. If these messages can
> be very frequent (say device orientation & network condition messages),
> this will soon bloat D-BUS memory usage quite a bit. After D-BUS
> starts to swap, it won't perform very well.

Ok, so much for the easy hack.

What you say above has other sinister overtones as well - an
application that is listening to frequent dbus signals has no way of
getting swapped out, or staying swapped out (it can stay mapped in for
days without doing any useful work at all).

I don't think real applications out there have a habit of
unsubscribing from dbus signals when they don't need them either.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


sivan at omniqueue

Sep 20, 2010, 1:38 PM

Post #10 of 14 (940 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Mon, Sep 20, 2010 at 4:35 PM, Eero Tamminen <eero.tamminen [at] nokia> wrote:
> For example D-BUS will infinitely buffer messages that are sent
> to a connected client but not read by it. If these messages can
> be very frequent (say device orientation & network condition messages),
> this will soon bloat D-BUS memory usage quite a bit. After D-BUS
> starts to swap, it won't perform very well.

Without getting too much into the details, can't dbus be set a
threshold for the buffer size so after X events that are still waiting
it would stop dispatching and just ignore new incoming events? This
can probably prevent it from swapping but will have a cost in the lost
events. However, if those events are constantly arriving then my guess
is that we can afford to lose them to some degree. (especially if
there are network condition messages and orientation events, at most
times orientation events acted upon tend to interfere with other uses,
while using the number pad to do DTMF while in call)

-Sivan
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


jknutar at nic

Sep 20, 2010, 7:22 PM

Post #11 of 14 (928 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Sunday 19 September 2010, Andrew Flegg wrote:
> On Sun, Sep 19, 2010 at 17:58, Robin Burchell <viroteck [at] viroteck>
wrote:
> > Anyway: this was pretty much in keeping with my idea: move it into
> > the task switcher (hildon-desktop/other) so that applications which
> > are moved to background are stopped (unless they signal for
> > whatever reason that they need to be kept running, but I'm not even
> > sure that is necessary: if you really need to do background
> > processing constantly, why do it in a GUI application?)
>
> I suggested something similar three years ago (wow, Maemo's old ;-))
> and the reaction was less favourable:

I tried doing something similar on Maemo 4, except my objective was to
SIGSTOP processes for 5-30 seconds at a time during heavy swap load so
that the tablet didn't blink into the blue Nokia logo and lose all
unsaved work.
Oddly what I discovered was that even with an unloaded system, stopping
apps usually hung the entire thing, and upon sending SIGCONT, I was
greeted by the "$APP is not responding blah blah", quickly followed by
the "now responding" message..

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


th.perl at gmail

Sep 21, 2010, 3:37 AM

Post #12 of 14 (929 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

2010/9/20 Ville M. Vainio <vivainio [at] gmail>:
> I don't think real applications out there have a habit of
> unsubscribing from dbus signals when they don't need them either.

Yes, that's what listening for D-Bus signals is all about most of the
time (getting notified when something of interest happens, which can
happen at any time, hence there's no real possibility to unsubscribe).

IIRC D-Bus signal filter/receiver rules are checked in the D-Bus
daemon, so moving most of the checks into the rule instead of checking
for simple things in the callback reduces the wake-ups, right? It's
not something that we can do automated, but it would be nice to add
some info on how to write good, powerful match rules to the relevant
"power saving" Wiki pages. For example, is it possible to compare
parameters of D-Bus signals in the rule (say, the second parameter is
equal to "disconnected"), so we don't need to receive signals that we
won't process/need anyway?

Thanks,
Thomas
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


maemo at csipa

Sep 23, 2010, 12:47 PM

Post #13 of 14 (910 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

On Monday 20 September 2010 17:35:34 you wrote:
> There are some potential downsides for just suspending processes
> completely. Most of the processes have subscribed to several
> different D-BUS messages, X events etc.
>
> For example D-BUS will infinitely buffer messages that are sent
> to a connected client but not read by it. If these messages can
> be very frequent (say device orientation & network condition messages),
> this will soon bloat D-BUS memory usage quite a bit. After D-BUS

Hmm... the external launcher that suspends is meant for apps that cannot
really handle/listen to dbus in the first place - if they can, they should
react to the lose-focus / screen off messages directly, not through
intermediary daemons, right ?

Best regards,
Attila Csipa
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers


eero.tamminen at nokia

Sep 24, 2010, 8:01 AM

Post #14 of 14 (899 views)
Permalink
Re: suspendprocess - poor man's power save [In reply to]

Hi,

ext Attila Csipa wrote:
> On Monday 20 September 2010 17:35:34 you wrote:
>> There are some potential downsides for just suspending processes
>> completely. Most of the processes have subscribed to several
>> different D-BUS messages, X events etc.
>>
>> For example D-BUS will infinitely buffer messages that are sent
>> to a connected client but not read by it. If these messages can
>> be very frequent (say device orientation & network condition messages),
>> this will soon bloat D-BUS memory usage quite a bit. After D-BUS
>
> Hmm... the external launcher that suspends is meant for apps that cannot
> really handle/listen to dbus in the first place
> - if they can, they should react to the lose-focus / screen off messages
> directly, not through intermediary daemons, right ?

All UI apps (including SDL games) get focus events and can react to
them. If e.g. game continues although it's not focused i.e. user
cannot interact with it, that's pretty bad usability.

But games ported from Desktop might still be showing e.g. some
"pause" animations when they aren't focused. If they aren't on D-BUS,
suspending might be an OK hack for them. IMHO it's better to fix
the program properly though, but that takes more time...


- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers

Maemo developers RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.