On 07/16/2016 08:48 PM, Thomas Voß wrote:
On Sat, Jul 16, 2016 at 8:25 PM, รัชนันท์ ศรีรัตนเมธ
<peathot@xxxxxxxxxxx> wrote:
<snip>
In Ubuntu touch, I have no idea where oom_adj is computed. (Please anyone
tell me?) But from my experiment, all suspended applications have the same
value of oom_adj. How this affects the problem? Imagine this:
You are almost right, but we are not using Android's lowmemorykiller, yet.
Instead, we configure the vanilla OOM killer by altering oom_score_adj
(oom_adj is deprecated).
Android's lowmemorykiller sits on top of this mechanism and allows for
specifying ranges of memory
and mappings to oom{_score}_adj values.
As you describe later, we are not yet deploying a heuristic that
assigns a higher oom_score_adj value
to app instances that have been used less recently (think about: least
recently used is more likely to be killed under the assumption
of a uniform distribution of memory usage). The respective feature is
under development iirc, but I'll
let Gerry and Ted comment on this explicitly (I CC'ed both of them explicitly).
Thomas is correct, while we're setting an OOM score to influence the OOM
killer's decisions, we currently set the same OOM score for all
background apps, irrespective of how recently they were used.
We're now working on more advanced OOM score calculation, so that a
recently-used background app is less likely to be killed than one used
less recently. This bug tracks that task:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1579799
<snip>
2.Ubuntu touch's choice for using QML. Out of curiosity, I opened an SSH
session, ran "top", and looked at the calculator app's memory usage on my
phone. I found out it's around 113 MB. 113 MB just for a caculator!? I'm
speechless.
I believe this can be reduced somehow. One of the idea is that, as many QML
component in Ubuntu is shipped as source .qml files, I understand that each
application will have to load those files, parse that files, and keep those
parsed code individually in each application's memory (please correct me if
I'm wrong). As many Android kernel has enabled KSM (kernel samepage
merging), maybe we should try exploiting it? I've tried enabling KSM on my
device, but the result was pretty disappointing. Maybe we should mark those
memory as mergeable?
I think we should take the time and analyze memory usage first before
starting to optimize.
Specifically, for the reported 113 MB, is that RSS, USS or PSS?. I
don't have a phone with ssh handy right now
but I will try to reproduce your test case tomorrow first thing. I
would start analyzing /proc/$pid/smaps first.
I would also propose to establish a memory baseline measurement by
considering a very simple QML app just displaying a rectangle.
That should give a reasonable baseline for comparisons. Even if the
calculator is simple, it still puts its own app logic on top (stack of
calculations etc.).
QML is a very easy language to use, but that has a consequence: it is
easy to write code in a memory wasteful manner.
One can easily write code that loads all the views your application will
ever have into memory - even though only one view is shown at a time. It
just takes a little care to properly load/unload views to lower your
memory use (using the UITK will help with that).
It is too easy to load big images into memory and scale them down on the
GPU. Complex QML widgets can be expensive in memory too - the UITK team
are working on rewrite existing QML widgets to be more efficient.
The sad truth is that when developing an application, monitoring memory
usage is one of the last things thought of!
To address thing we're working on a performance monitoring system to
give a high-level perspective on application resource usage
(CPU/memory/IO...), so we can quickly identify wasteful apps and help
them improve. Watch this space!
Thanks for sharing your thoughts.
-Gerry
