1475889 - Memory pressure events not fired on Linux

Status: RESOLVED DUPLICATE of bug 1532955

(Core :: XPCOM, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Currently memory-pressure events can be fired on Android and Windows, but never on desktop Linux as far as I can tell. Apart from the fact that they might be useful on Linux, this means there is no way to reproduce memory-pressure-related bugs on Linux under rr.

Is there any interest in adding memory-pressure detection for desktop Linux? If so, how should it work? It looks like a polling approach similar to Windows in xpcom/base/AvailableMemoryTracker.cpp should be possible by reading /proc/meminfo, but I'm not sure exactly when to trigger low-memory. Perhaps checking MemAvailable?

> MemAvailable %lu (since Linux 3.14)
>   An estimate of how much memory is available for starting new applications, without swapping.

It's hard to say what the threshold should be ... wild guess, min(128MB, 1% of MemTotal)? Any non-zero threshold would let us fake /proc/meminfo results in rr to trigger memory pressure notifications.

Comment 1

[Nicholas Nethercote [inactive]]

Gabriele has been looking into memory pressure lately, and may have some opinions.

Comment 2

[Gabriele Svelto [:gsvelto] (PTO)]

Yeah, memory-pressure events and memory tracking has never been implemented in Linux. The new polling method introduced in bug 1451005 could be used on Linux too but there's a few gotchas to take into account: opening/reading /proc/meminfo would be blocking so doing so on the main thread is not a good idea. I don't if it's possible to call an nsITimer callback on a background thread but if it is then it would be preferable (for Windows too obviously). Another issue is deciding what to measure and what would be the appropriate thresholds for sending memory-pressure events. Right now we don't have much data regarding Linux/Mac OOM crashes. It might be worth adding annotations like we have on Windows [1] and populate them with the information in /proc/meminfo. This should probably include swap information since it's not accounted for in MemAvailable.

https://searchfox.org/mozilla-central/rev/b0275bc977ad7fda615ef34b822bba938f2b16fd/toolkit/crashreporter/nsExceptionHandler.cpp#733

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> opening/reading /proc/meminfo would be blocking so doing so on the main thread is not a good idea

I suspect it's not really a problem. Reads from /proc are handled directly by the kernel and don't actually do any I/O.

Comment 4

[Robert AB]

Probably not correct connection. Should this bug (Bug 1475889) block Bug 1553260 or Bug 675539?

Comment 5

[Gabriele Svelto [:gsvelto] (PTO)]

Good point, I mixed up the two bugs.

Comment 6

[Chris Peterson [:cpeterson]]

Kris, I'm assigning this bug to you because I've been told that you will help integrate Linux's memory pressure events with Firefox tab unloading. Thanks!

Comment 7

[Chris Peterson [:cpeterson]]

Tab unloading is a nice-to-have for our Fission Release experiment, but doesn't need to block it. I will move this bug from Fission Milestone M8 to MVP.

Comment 8

[Chris Peterson [:cpeterson]]

This bug is a soft blocker for Fission MVP. We'd like to fix it before our Release channel rollout, but we won't delay the rollout waiting for it.

Comment 9

[Chris Peterson [:cpeterson]]

Clearing Fission Milestone because firing memory pressure doesn't need to block shipping Fission MVP on Linux.

Comment 10

[Haik Aftandilian [:haik]]

@Kris, OK to close this now that bug 1532955 has landed?

Comment 11

[Kris Wright :KrisWright]

Yes, this work was finished as a part of bug 1532955. :)