[Suggestion] Configurable OOM management (apps killing)

asked 2014-12-02 19:49:49 +0200

9595 ●94 ●124 ●122

updated 2014-12-02 19:51:43 +0200

As announced in the update 10 announcement, Jolla is trying to solve system lagging by introducing an 'out of memory' (OOM) manager that would kick in and suspend apps if the system was running low on memory.

Please, make this configurable.

With Ubuntu Touch recently going the same path as Android/iOS and killing apps automatically, there is even more need for a system with real multitasking where the user decides what is running and what is not. I was buying Jolla to use this kind of multitasking and I would be very sad to see it gone/crippled.

As I think: Running too many apps is my problem, not the system's problem.

EDIT: I do know that this kind of management already exists in Linux, it is just a matter of its configuration and I would like to see this configuration exposed to the user.

edit retag flag offensive close delete

Comments

It seems to me that the announcement speaks about tuning the Linux built-in OOM killer and letting the Jolla applications release memory when they don't need it, not about some custom OOM manager. Have you read the same in a different way?

tanriol ( 2014-12-02 21:19:48 +0200 )edit

@tanriol Yes, see my edit (edited just after the original post).

nodevel ( 2014-12-03 02:36:22 +0200 )edit

@nodevel, I'm not sure it can be sensibly exposed... AFAIK it cannot be disabled (and if it were OOM would likely lead to a complete hang, which is worse than killing a single application). Would you suggest providing users with sliders for every app's priority? Won't it feel as too much micromanagement?

tanriol ( 2014-12-03 08:18:43 +0200 )edit

For average Joe users, like me, such configuration options would make the phone only a bit overwhelming / confusing.

anandrkris ( 2014-12-03 13:10:23 +0200 )edit

@anandrkris Why? :) Having an option in the settings means you need to press it? Average Joe users would never have to use it, but if you worry about touching options you have no idea what they do (which you shouldn't do in the first place), then let Jolla put it in 'Developer mode' or 'Sailfish Utilities' sub-folder.

nodevel ( 2014-12-03 13:27:19 +0200 )edit

answered 2014-12-25 22:05:14 +0200

tortoisedoc

11414 ●172 ●269 ●287

http://kastlunger.blogspo...

updated 2014-12-25 22:13:03 +0200

My two cents :

policy for individual apps for oom situation managememnt, definable by developer
"default" policy implemented by oom based on libraries which the app links against; for example, audio player would be safe from removal If playing during high mem consumption situations (due to its use of audio libs). these default policies would then of course also override eventual developer configurations.

Now, im not a smart person, and I am sure someone else has alreday thought about this, which means its potentially patented. which might explain why android has not gone down this route. But surely if the case applies, there are workarounds to implement similar mechanisms.

Also, i do not believe the normal end user should be put in the position to have to handle this. As the average joe does not know about memory management, and for experts there is always the /proc system.

Comments

Most of it is already implemented and accessible through /proc and of course cgroups (where you can put group of processes and define whole oomkiller properties to them). I am not sure if it would make sense for an end user to configure this. Sane defaults are better.

leszek ( 2014-12-25 22:53:46 +0200 )edit

[Suggestion] Configurable OOM management (apps killing)

Comments

1 Answer

Comments

Question tools

Stats

Related questions

[Suggestion] Configurable OOM management (apps killing)

Comments

1 Answer

Comments

Question tools

Public thread

Stats

Related questions