ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Grawert wrote on 06/08/15 16:35:
> 
> Am Donnerstag, den 06.08.2015, 14:33 +0100 schrieb Matthew Paul 
> Thomas:
> 
>> Many people do not understand this. Even worse, they think the 
>> opposite -- that closing apps will make their phone faster 
>> somehow. This is understandable if they're used to PCs, which do 
>> work the way they imagine: background apps can consume
>> processing time, and by sitting in RAM they may cause a
>> foreground app to use slow swap space instead. But neither is the
>> case in Ubuntu Touch. Background apps are put to sleep, so they
>> don't take up processing time.[1] And swap space is small, and
>> may not even exist at all in the long run,[2] because if memory
>> is really needed the OS can just close background apps
>> automatically.
> 
> we use zram across the board for swapping currently, not actual 
> swap space ... so you wont actually notice slowdowns when
> something swaps

That's good. But I was referring to PCs in general, as things that many
phone users are used to -- not just to PCs running Ubuntu, in versions
that don't even include the latest LTS. (Or OS X 10.9 and later.)

> while all of the above is correct it sadly doesn't really match 
> reality ... on a 1G device like krillin the app lifecycle 
> management (or rather the in-kernel lowmemorykiller that we use) 
> usually don't let you have more than 2-3 apps active in ram and
> you end up with OOM killed apps a lot ...

It doesn't matter how many apps fit in memory. Regardless of the
number, it is more efficient for Ubuntu Touch to purge apps from
memory when and only when it's necessary, than for a user to try and
guess when it's necessary. And that's not even counting the time the
person wastes doing it.

> if an app gets OOM killed it will be completely flushed from RAM, 
> there is only a screenshot in unity8 representing it ... once you 
> flip this app back into foreground in the UI it will be loaded from
> disk, this isn't much different from swapping to disk or any other
> disk I/O operation, so all you do is to move the slowness into
> another place.
> 
> if you now take away the ram for one unkillable app on a 1G device 
> your possible app count goes down from 3 to 2 before you cause any 
> slowness by re-loading the apps, so on these devices it matters a 
> lot if you keep an unkillable app running or not just to
> compensate for its slow startup time.
> 
> ...

Exactly. The best possible scenario is that you'd be keeping an app in
memory that, in the current scheme, would have stayed in memory
anyway. Most of the time, though, you'd be hogging memory that could
have been used by apps you were using more often.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlXHJvkACgkQ6PUxNfU6ecpg9QCfWhFnJi6dYT4uoeuG0YShPfKa
tIYAn0tD5CQ0K6dVE9FK2juoYnu2Q/7A
=ffve
-----END PGP SIGNATURE-----