Preallocated process takes more memory in FFOS 2.0

RESOLVED WORKSFORME

Status

Firefox OS
Performance
P1
blocker
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: tkundu, Unassigned)

Tracking

({footprint, perf, regression})

unspecified
2.0 S5 (4july)
ARM
Gonk (Firefox OS)
footprint, perf, regression

Firefox Tracking Flags

(blocking-b2g:2.0+)

Details

(Whiteboard: [c=memory p= s= u=2.0] [MemShrink:P2])

Attachments

(2 attachments)

Preallocated process shows 5837KB PSS and 4620KB USS in |b2g-procrank| on FFOS v1.3

But it shows 6563KB PSS and 5548 KB USS in |b2g-procrank| on FFOS v2.0

It seems like memory regression is almost 1MB in FFOS 2.0. It can become a bottleneck for 256MB FFOS 2.0 device.
blocking-b2g: --- → 2.0?
Component: General → Performance

Updated

3 years ago
Keywords: perf
Whiteboard: [c=memory p= s= u=]

Updated

3 years ago
blocking-b2g: 2.0? → 2.0+
Keywords: footprint
Whiteboard: [c=memory p= s= u=] → [c=memory p= s= u=] [MemShrink]

Updated

3 years ago
Keywords: regression
I'll update with detailed memory reports for 1.3, 1.4, 2.0.
Flags: needinfo?(erahm)
NAME             PID   PPID  CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER
Preallocated 1.3 19834 937    1.6   18    4.2  5.7 17.5  59.7  10     root     
Preallocated 1.4 1023  835    0.6   18    4.8  8.5 17.3  59.2  10     u0_a1023
Preallocated 2.0 1079  842    0.6   18    5.2  7.1 18.2  60.8   1     u0_a1079
Preallocated 2.1 1083  834    0.6   18    5.4  7.4 18.5  60.4   1     u0_a1083

Looks like the primary regression is from 1.4 -> 2.0 (+1.1MB RSS), then 2.0 -> 2.1 (+0.3MB RSS). 

I'm not seeing anything jump out in an about:memory diff of 1.4->2.0. We do see heap-unclassified has increased the most, but the total explicit delta is about 0.7MB less than the observed increase:

0.38 MB (100.0%) -- explicit
├──0.62 MB (164.55%) ── heap-unclassified
├──-0.01 MB (-3.67%) ++ heap-overhead
├──-0.13 MB (-32.99%) ── xpti-working-set
├──-0.05 MB (-14.50%) ++ js-non-window
├──-0.04 MB (-11.36%) ++ window-objects/top(about:blank, id=1)
├──-0.03 MB (-8.54%) ++ xpconnect
├──0.02 MB (04.19%) ── layout/style-sheet-cache
├──0.01 MB (02.09%) ── preferences
└──0.00 MB (00.21%) ++ (4 tiny)

 0.42 MB ── heap-allocated
-0.17 MB ── heap-committed
 -12.75% ── heap-overhead-ratio
 0.02 MB ── js-main-runtime-temporary-peak
    -274 ── page-faults-soft
 1.24 MB ── resident
 0.36 MB ── resident-unique
 1.57 MB ── vsize

And 2.0 -> 2.1 is equally confusing (here heap-unclassified is down 1.2MB, but that could be due to better reporting):

-1.09 MB (100.0%) -- explicit
├──-1.12 MB (102.66%) ── heap-unclassified
├──-0.01 MB (01.24%) ++ js-non-window
├───0.02 MB (-1.72%) ++ heap-overhead
├───0.02 MB (-1.43%) ── xpti-working-set
└───0.01 MB (-0.75%) ++ (8 tiny)

-1.15 MB ── heap-allocated
      -2 ── heap-chunks
-1.19 MB ── heap-committed
-2.00 MB ── heap-mapped
   3.44% ── heap-overhead-ratio
 0.04 MB ── js-main-runtime-temporary-peak
     213 ── page-faults-soft
-0.09 MB ── resident
 0.20 MB ── resident-unique
-0.39 MB ── vsize
Flags: needinfo?(erahm)
Created attachment 8445400 [details]
about-memory-reports.tar.bz2

get_about_memory.py results for pvt eng builds of the latest 1.3, 1.4, 2.0 (aurora), 2.1 (central). Exact gecko/gaia versions are including in each folder as b2g-version
Whiteboard: [c=memory p= s= u=] [MemShrink] → [c=memory p= s= u=] [MemShrink:P2]
The memory consumed by the Nuwa process appears to have decreased, so it's possible we just "moved" memory from one process to the other.

I'm far more concerned about bug 1029902 than this.

Updated

3 years ago
Severity: normal → blocker
Whiteboard: [c=memory p= s= u=] [MemShrink:P2] → [c=memory p= s= u=2.0] [MemShrink:P2]

Comment 5

3 years ago
Eric,

Can you take this one? Kyle's occupied with bug 1029902 and we need help with resolving Memory performance issues.

Thanks,
FxOS Perf Triage
Flags: needinfo?(erahm)

Comment 6

3 years ago
From IRC it appears the memory reports in comment 3 did not use the -m flag for minification.  Given that the flame has so much memory these were taken without any memory pressure.  So changes could just reflect temporary stuff that would be flushed when pressure occurs.

I would recommend checking with the -m flag.

Tapas, how much memory does the device your testing on have?  Did you force memory minification with -m?
Flags: needinfo?(tkundu)
> minification

FWIW, your use of this term totally confused me. I thought you were talking about minification of source code, i.e. rewriting it to take less space. I think "minimization" is less confusing :)
Created attachment 8446868 [details]
comparison between v1.3 and v2.0 preallocate process.tar.bz2

(In reply to Ben Kelly [:bkelly] from comment #6)
> From IRC it appears the memory reports in comment 3 did not use the -m flag
> for minification.  Given that the flame has so much memory these were taken
> without any memory pressure.  So changes could just reflect temporary stuff
> that would be flushed when pressure occurs.
> 
> I would recommend checking with the -m flag.
> 
> Tapas, how much memory does the device your testing on have?  Did you force
> memory minification with -m?

I attached it here. I used |adb reboot && sleep 60| in both FFOS v1.3 and FFOS v2.0 and I also used command [1] to get this report on both platform.

It shows me almost 1MB regression between v2.0 and v1.3 .

[1] |MOZ_IGNORE_NUWA_PROCESS=1 ./device/qcom/b2g_common/mozilla-b2g/tools/get_about_memory.py --minimize --gecko-objdir=./out/target/product/msm8610/obj/objdir-gecko/|
Flags: needinfo?(tkundu)
Looks like Tapas and I are on the same hunt, I did my own measurements for 1.4, 2.0, 2.1. If we look at the whole picture including Nuwa's stats I think overall this is a non-issue.

Nuwa RSS went down from 1.4 -> 2.1 by 1.25, Preallocated went up by 1.25. Nuwa USS went down by 1.5, Preallocated went up by 0.65. So overall things are _slightly_ better now if we combine Nuwa and Preallocated stats. 

It does look like there's a slight regression from 2.0 -> 2.1: combined RSS went up ~0.5 and combined USS went up 0.825.

I'm inclined to close this as works for me, but can look into things further if needs be.

Averages of 4 measurements after a reboot each time.

Preallocated averages:
                  	USS	PSS	RSS	VSIZE
1.4 - Preallocated	4.6	8.325	17.125	59.2
2.0 - Preallocated	4.6	7.325	17.625	60.8
2.1 - Preallocated	5.25	7.975	18.375	60.4

Preallocated average deltas:
		USS	PSS	RSS	VSIZE
1.4 -> 2.0	0	-1	0.5	 1.6
2.0 -> 2.1	0.65	 0.65	0.75	-0.4
1.4 -> 2.1	0.65	-0.35	1.25	 1.2

Nuwa averages:
		USS	PSS	RSS	VSIZE
1.4 - Nuwa	3.9	9.425	20.95	52.2
2.0 - Nuwa	2.225	7.15	19.925	53.8
2.1 - Nuwa	2.4	7.125	19.7	53.4

Nuwa average deltas:
		USS	PSS	RSS	VSIZE
1.4 -> 2.0	-1.675	-2.275	-1.025	1.6
2.0 -> 2.1	0.175	-0.025	-0.225	-0.4
1.4 -> 2.1	-1.5	-2.3	-1.25	1.2
Flags: needinfo?(erahm)

Comment 10

3 years ago
Tapas,

Per Eric's findings and recommendation in comment 9 we intend to close this as WFM. Please confirm your agreement or indicate why you disagree.

Thanks
Flags: needinfo?(tkundu)
(In reply to Mike Lee [:mlee] from comment #10)
> Tapas,
> 
> Per Eric's findings and recommendation in comment 9 we intend to close this
> as WFM. Please confirm your agreement or indicate why you disagree.
> 
> Thanks

Please close it. It seems to me very reasonable now.
Flags: needinfo?(tkundu)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Updated

3 years ago
Target Milestone: --- → 2.0 S5 (4july)
You need to log in before you can comment on or make changes to this bug.