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.

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

> 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.