Closed Bug 1652813 Opened 4 months ago Closed 3 months ago

Switch about:processes to use resident-unique rather than resident memory

Categories

(Core :: DOM: Content Processes, task, P2)

task

Tracking

()

RESOLVED FIXED
81 Branch
Fission Milestone M6b
Tracking Status
firefox81 --- fixed

People

(Reporter: nika, Assigned: Yoric)

References

Details

Attachments

(4 files)

We should switch our memory usage column in about:processes to use resident-unique, rather than resident memory. From some quick testing, this matches the behaviour of the gnome system monitor program, and of chrome's Task Manager UI. By using resident, we're showing a less useful number which will report higher-than-actual memory usage for Firefox.

This can probably be done at the same time as bug 1648378.

Flags: needinfo?(dteller)

Good idea. I'll need to determine what resident-unique maps to under macOS and Windows.

Flags: needinfo?(dteller)

We report it in about:memory, so digging around in the memory reporter code should reveal how we get it on different platforms, or maybe you can call into existing code.

Severity: -- → S2

So, as usual three very different implementations:

Looks like I could patch them to make them usable from the browser process without waking up child processes. I just hope that the Windows version won't have these crazy performance issues we've encountered elsewhere (e.g. bug 1652000).

Assignee: nobody → dteller
Fission Milestone: --- → M6b
Attached image Screenshot.png

Testing under Linux, the memory we report with resident-unique is still larger than whatever Gnome reports. Do you think I should investigate further or will this be sufficient for M6?

Note that I'm a little dubious when gnome tells me that none of my processes uses CPU.

Flags: needinfo?(nika)

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #5)

Testing under Linux, the memory we report with resident-unique is still larger than whatever Gnome reports. Do you think I should investigate further or will this be sufficient for M6?

I think this is caused by us using a different definition of resident-unique than gnome does, based on this comment. https://searchfox.org/mozilla-central/rev/d6d8fcc22c3820f2ae08229e0d37be19fba74db9/xpcom/base/nsMemoryReporterManager.cpp#90-94

  // You might be tempted to calculate USS by subtracting the "shared" value
  // from the "resident" value in /proc/<pid>/statm. But at least on Linux,
  // statm's "shared" value actually counts pages backed by files, which has
  // little to do with whether the pages are actually shared. /proc/self/smaps
  // on the other hand appears to give us the correct information.

The gnome system monitor, in contrast, appears to compute the value it displays in the "tempting" way (though I haven't confirmed that libgtop directly fetches the values from statm, I imagine they're the same). https://github.com/GNOME/gnome-system-monitor/blob/f655eff6424f4c01b9d42efb7e25344c396ba692/src/proctable.cpp#L759-L762

    info->mem = info->memres - info->memshared;

Doing the computation in the gnome way might be more efficient than manually counting pages from /proc/<pid>/smaps , but imo it's fine for now, and I don't think we need to change about:processes until it proves to be an issue.

Flags: needinfo?(nika)
Attachment #9164372 - Attachment description: Bug 1652813 - Extract resident unique size in GetProcInfo;r?tarek → Bug 1652813 - Extract resident unique size in GetProcInfo;r?tarek!
Attachment #9164373 - Attachment description: Bug 1652813 - Display resident-unique memory instead of resident + virtual;r?florian → Bug 1652813 - Display resident-unique memory instead of resident + virtual;r?florian!
Attachment #9163743 - Attachment description: Bug 1652813 - Provide an API to get the resident unique memory of a process without waking it up;r?njn → Bug 1652813 - Provide an API to get the resident unique memory of a process without waking it up;r?njn!
Pushed by dteller@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/96cc9b2430a7
Provide an API to get the resident unique memory of a process without waking it up;r=njn
https://hg.mozilla.org/integration/autoland/rev/cc87a15368d0
Extract resident unique size in GetProcInfo;r=froydnj
https://hg.mozilla.org/integration/autoland/rev/b0d012ec753d
Display resident-unique memory instead of resident + virtual;r=florian,fluent-reviewers
Regressions: 1661274
You need to log in before you can comment on or make changes to this bug.