ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #21628
Re: Memory..
Hello,
On 17/07/2559 02:48, 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).
Thanks for correcting me. Although I'm not sure if it's actually OOM
killer because I still see LMK's config in /sys/module/lowmemorykiller/.
For oom_score_adj computation, could you tell me which code is
responsible for dealing with it? I just want to understand how it's managed.
<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.).
Ha-ha. Seems like I was in bad mood at that moment. Sorry!
For 113 MB number I gave it to you, it's RES field in "top" for qmlscene
process corresponding to calculator application. I also agree to you
that we should analyze memory usage first.
Anyway, I'm really suspect that QML code in different process can't be
shared. Could you please give me some pointer where I can study about that?
Thank you,
Ratchanan Srirattanamet.
Sorry for a rather long e-mail, but I just want to share my though about how
low memory situation could be resolved. Maybe all I've said is a crap, then
please give me the correct knowledge.
On the contrary: Thanks for your thoughts and ideas :)
Cheers,
Thomas
Ratchanan Srirattanamet
PS. It seems like browser session won't restore after being killed in
background on my device. Does it works on other device? rc-proposed build
20160715-092035.
References