ubuntu-phone team mailing list archive

[Gerry Boland <gerry.boland@xxxxxxxxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature