Improvement suggestion: Add a SIGSTOP toggle to 'background' applications to reduce system load

[buzztiaan]

On #maemo-leste it became consensus quickly that it would be a nice feature to expand hildon to be able to SIGSTOP/SIGCONT applications on demand. That way , you could stop firefox from slurping up cputime when you're actually working somewhere else.

tmlind suggested to just have a cgroup that all get sigstop on lcd blank :)

19:34:29 < Wizzup> 18:54 < uvos> you know what would be a killer feature for 
                   hildon: a toggle in the title bar that if selected 
                   automaticly sends signal 19 / signal 18 to the process that
19:34:32 < Wizzup>               owns the window when its window is 
                   focused/unfocused.
19:34:34 < Wizzup> this exists
19:41:21 < uvos> sweet where?
19:42:21 -!- xsetiadi [~xsetiadi@114.125.233.172] has joined #maemo-leste
19:48:54 < Wizzup> uvos: trying to find
19:50:21 < Wizzup> uvos: http://talk.maemo.org/showpost.php?p=1005668&postcount=1
19:50:33 < Wizzup> someone turned this into something you can use to wrap 
                   launchers in
19:50:37 < Wizzup> trying to find it
19:51:06 < Wizzup> there was a better tool but I'm having trouble finding, but 
                   maybe sicelo or freemangordon remembers
19:55:04 < buZz> uh, doenst maemo already have that?
19:55:39 < buZz> i vaguely remember a 'kill current app' button somewhere
19:58:42 < sicelo> buZz: power button while application is in focus. but i think 
                   uvos is talking about SIGSTOP, not SIGKILL/HUP
19:58:54 < uvos> buZz:  we are talking SIGSTOP not signal SIGKILL
20:00:00 < sicelo> Wizzup: i don't remember the tool, although i knew about this 
                   tmo thread (and was looking at it only a day or two agowhile 
                   learning some dbus-fu)
20:00:23 < uvos> buZz: SIGSTOP hildon integration would allow us to have a 
                 android-like "allow runing in background" permission.
20:01:07 < uvos> greatly extending battery life with desktop applications 
                 running since they generaly dont care about power usage.
20:01:20 < buZz> ah!
20:01:35 < sicelo> uvos: but we don't really need that, do we? we already allow 
                   running im background because we're a true multitasking 
                   system unlike Android
20:01:59 < buZz> well, maybe that button-that-sends-signal could easily be 
                 copied to button-that-sends-a-different-signal ?
20:02:15 < uvos> sicelo:  right, this is about selectivly _not_ allowing 
                 applicatons to run in background
20:02:22 < buZz> if you can check externally if some PID is stopped, you could 
                 make it a toggle without much effort
20:02:40 < uvos> it makes no sense wasting power flashing the cursor in 
                 libreoffice while libreoffice is in background
20:02:41 < uvos> etc
20:02:43 < buZz> would be a great maemo improvement even
20:03:02 < buZz> sigstop firefox for instance, so you dont waste cputime on 
                 animated gif
20:03:22 < sicelo> hildon has the ossi framework/services (which i also only 
                   lreabed about in a couple of days ago), which allows 
                   applications built against that library to respond to a ha
20:03:45 < sicelo> ibernate signal (i guess that's SGSTOP)
20:03:59 < buZz> ahh ok
20:04:02 < uvos> you cant respond to SIGSTOP
20:04:06 < buZz> thats the python-osso aswell?
20:04:06 < sicelo> *hibernate (sorry, typing on android)
20:04:22 < buZz> touchscreen*
20:04:23 < buZz> :P
20:04:39 < sicelo> buZz: yes @python-osso.
20:05:00 < uvos> SIGSTOP just stop the process from the process from getting any 
                 cpu time, you uniquly amoungst signals cant trap it.
20:05:13 < uvos> aside from SIGKILL you cant trap that either
20:05:37 < uvos> *SIGSTOP just stops the process from getting any cpu time, you 
                 uniquly amoungst signals cant trap it.
20:06:10 < sicelo> i guess you can open a GH issue (marked as an enhancement 
                   perhaps) for future implementation.
20:06:34 < sicelo> i doubt we're at that point yet
20:06:41 < buZz> no harm in opening a issue
20:07:02 < buZz> leste is getting more and more attention, maybe someday ppl 
                 will just pickup random unassigned issues
20:07:04 < buZz> :)
20:07:16 < buZz> shall i make one?
20:07:33 < uvos> go ahead
20:07:45 < tmlind> yeah that way it's at least documented
20:07:48 < uvos> mention this: [19:03] <tmlind> uvos: or just have a cgroup that 
                 all get sigstop on lcd blank :)
20:08:05 < uvos> thats the best idea i think
20:09:15 < buZz> whats the unSIGSTOP called again, SIGCONT ?
20:09:22 < uvos> jup
20:09:28 < uvos> sig 18
20:10:09 < tmlind> oh cool the cgroup freezer stuff has docs in kernel at 
                   Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
20:10:37 < buZz> tmlind: but does lcd blank apply when you're just switching to 
                 a different application?
20:10:47 < buZz> or could you toggle the cgroup state from a gui button aswell
20:11:05 < tmlind> buZz: well you can make up any policy for the group, see the 
                   doc i linked for some examples
20:11:22 < buZz> alright
20:11:26 < tmlind> so we could have screen_blanked group and not_visible group
20:11:31 < buZz> i still think a per-application one would be nice aswell
20:11:40 < buZz> oh, can you make running applications change group?
20:12:29 < tmlind> yeah see the xamples: echo $some_pid > 
                   /sys/fs/cgroup/freezer/0/task
20:12:49 < tmlind> sorry should be tasks not task

[MerlijnWajer]

Found what I meant: https://www.mail-archive.com/maemo-developers@maemo.org/msg27190.html

[dderby]

I've often thought that something like that would be nice to have, not necessarily in the title bar, but maybe a "pause" button on each app in the task manager.

It would be really nice if it supported not only SIGSTOP/SIGCONT, but also checkpoint/restore to suspend the process to disk in order to free up memory. This would be particularly useful on devices like the N900 which don't have very much physical memory.

[freemangordon]

I don't think it is a good idea to automatically stop/suspend an application - this is what android does more or less, so, please, lets not go that route. If an application is not optimized - well, either fix it or just stop (using) it.

[MerlijnWajer]

I don't see why users can't use these launchers for programs they want to use. I agree that the maemo core should be PM friendly, but if a user wants to use Firefox and suspend it on device lock, why stop them?

[freemangordon]

If it is implemented as a kind of a blacklist (like list of applications or a parameter in the .desktop file) to be suspended when in background and not a permission "allow running in background", then it might be ok. However, I think hildon already have some support for "hibernating" an application, though I have no idea how and where

[MerlijnWajer]

Agreed regarding blacklist / upon request, rather than default/heuristic based. I think what I posted above is as close as 'anything integrated' goes.

[IMbackK]

solved https://github.com/IMbackK/sigstoped

[buzztiaan]

@freemangordon the suggestion wasnt really to make it automagical , but just extend the 'kill application' button in powermenu to have a 'stop/unstop application' button aswell

it could be through a service like @IMbackK suggests, but there's methods with even lower demands on system

[IMbackK]

@dderby this is not necessary the kernel already prioritizes swapping out processes in SIGSTOP.

[dderby]

@dderby this is not necessary the kernel already prioritizes swapping out processes in SIGSTOP.

@IMbackK, true, but checkpoint/restore would be more flexible. It wouldn't be limited by the available swap space and it would also persist between reboots.

I would prefer a user controlled solution, no automation, just a button on each app in the task manager to send a SIGSTOP or SIGCONT. I don't think we need a blacklist or daemon.

[MerlijnWajer]

@dderby this is not necessary the kernel already prioritizes swapping out processes in SIGSTOP.

@IMbackK, true, but checkpoint/restore would be more flexible. It wouldn't be limited by the available swap space and it would also persist between reboots.

I would prefer a user controlled solution, no automation, just a button on each app in the task manager to send a SIGSTOP or SIGCONT. I don't think we need a blacklist or daemon.

I have to disagree - if the goal is to make some applications behave properly from the user point of view, then stopping them in device lock seems like the right approach to me. If the user locks the device, he/she probably doesn't really want to go over every application that they have previously deemed 'power hungry' and close them all.

[MerlijnWajer]

In any case - I think this would go in -extras. As @freemangordon also said, if users want to user it to work around non-pm-friendly applications, let's do that. But our core will just be PM friendly.

[IMbackK]

Sigstoped is now in extras.

i gues this is solved(ish) by sigstoped. sigstoped dosent help with console applications only gui ones so maybe not fully.

[clort81]

Thank you IMbackK... I have wanted something like this to pause firefox (cpu hog) on other machines also.

To pause midori i add to sigstoped/blacklist midori WebKitNetworkProcess WebKitWebProcess

And midori obeys!

And it works on desktop too! Finally firefox browser stops chewing up my cycles displaying a static file!

THANK YOU IMbackK!

apt-get source sigstoped didn't work but i grabbed https://maedevu.maemo.org/extras/pool/main/s/sigstoped/sigstoped_1.0.6%2B2m7.tar.gz

sigstoped usage:

• create ~/.config/sigstoped/blacklist
• one proces name per line, nothing else
• run /usr/bin/sigstoped

Maybe usage information could be made visible to user via postinst script or manpage?

[IMbackK]

@clort81 glad you liked it.

explicitly stating WebKitNetworkProcess and WebKitWebProcess is unneseccary and can cause issues, sigstoped automaticly traverses the process tree and recursively stops all child processes. I agree documentation is currently lacking, ill improve it when i find the time for it. I dont know how to make apt source work :\ There is also qsigstoped to configure sigstoped in a graphical way. on leste also add --ignore-client-machine to your sigstoped launch otherwise sigstoped cant stop qt processes due to a bug in qt on leste.

[IMbackK]

@MerlijnWajer lets close this?