Filing as a good first bug to learn workflows.

On Linux, the "resident-unique" memory reporter (USS) is computed by parsing every entry of /proc/PID/smaps and summing Private_Clean + Private_Dirty across all mappings. The kernel already exposes those two numbers, pre-summed, in /proc/PID/smaps_rollup: a single block of about 700 bytes, instead of one 25-line block per mapping.

The change is to make ResidentUniqueDistinguishedAmount() read smaps_rollup directly (honouring its aPid argument, so it still works for other processes), and fall back to the existing GetProcSelfSmapsPrivate() path when smaps_rollup cannot be opened. The fallback is needed because smaps_rollup was added in Linux 4.14 and Firefox still supports older kernels.

Please do not change GetMemoryMappings() itself. Its other caller, the "memory-mappings" reporter, needs the full per-mapping detail and must keep parsing smaps.

Link to the code:

ResidentUniqueDistinguishedAmount(), the function to change:
https://searchfox.org/firefox-main/rev/298cf786229591e2159a3933605df11e07709d6f/xpcom/base/nsMemoryReporterManager.cpp#123

GetProcSelfSmapsPrivate(), the current implementation and the fallback:
https://searchfox.org/firefox-main/rev/298cf786229591e2159a3933605df11e07709d6f/xpcom/base/nsMemoryReporterManager.cpp#90

GetMemoryMappings(), the full smaps parser it calls:
https://searchfox.org/firefox-main/rev/298cf786229591e2159a3933605df11e07709d6f/xpcom/base/MemoryMapping.cpp#105

To verify the fix:

There is no unit test covering this value, so the check is that the reported number does not change.

1. Pick any running process and confirm the two sources agree:

   awk '/^Private_Clean:/{c+=$2} /^Private_Dirty:/{d+=$2} END{print c+d}' /proc/<pid>/smaps
   awk '/^Private_(Clean|Dirty):/{t+=$2} END{print t}' /proc/<pid>/smaps_rollup

   Both must print the same number of kB.

2. Build with ./mach build, then open about:memory and click "Measure". The "resident-unique" figure reported for each process must match what an unpatched build reports for a comparable session, and must match the awk numbers above for the corresponding pid.

Why this is worth doing: measured on a Firefox parent process with roughly 3000 mappings, parsing the full smaps costs about 10 ms per call. Around half of that is kernel time spent formatting about 2 MB of text, and around half is our own line-by-line parsing (one std::getline per line, plus an sscanf or strtok_r and a table lookup for each). Reading smaps_rollup costs about 3 ms. The page-table walk the kernel performs is identical either way, so roughly 7 ms of the 10 ms is avoidable.

Tutorial to contribute:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
https://firefox-source-docs.mozilla.org/contributing/stack_quickref.html

Please don't ask for the bug to be assigned. It will be automatically assigned to the first patch.

https://hg.mozilla.org/mozilla-central/rev/33574b7c70b2

Perfherder has detected a mozperftest performance change from push 33574b7c70b2327d3ea44aeaff02f8b6d3c320d0.

No action is required from the author; this comment is provided for informational purposes only.

Need Help or Information?

If you have any questions, please reach out to fbilt@mozilla.com. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

Surprisingly this perf improvement is real, apparently. Note that on Android however we do not gather memory telemetry (among others) on release, so end users will feel this less (but there is a smaller improvement for Linux, too, and that rides to release).