Open Bug 1475889 Opened 3 years ago Updated 2 months ago

Memory pressure events not fired on Linux


(Core :: XPCOM, defect)

Not set



Fission Milestone M8


(Reporter: roc, Assigned: KrisWright)


(Depends on 1 open bug, Blocks 1 open bug)


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.
Gabriele has been looking into memory pressure lately, and may have some opinions.
Flags: needinfo?(gsvelto)
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.
Flags: needinfo?(gsvelto)
> 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.
Component: Memory Allocator → XPCOM

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

Flags: needinfo?(gsvelto)

Good point, I mixed up the two bugs.

Blocks: 675539
No longer blocks: 1553260
Flags: needinfo?(gsvelto)
Blocks: 1587762
No longer blocks: 675539

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!

Assignee: nobody → kwright
Fission Milestone: --- → M8
See Also: → 1579198
Depends on: 1532955
You need to log in before you can comment on or make changes to this bug.