Hacker News new | ask | show | jobs
by gsvelto 1306 days ago
I'm glad you noticed! We did indeed roll an improvement on Linux too, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1771712

In a nutshell we're directing the OOM killer towards less interesting processes within Firefox so that when the system is low on memory they'll get killed first. This not only makes it more stable overall but it plays nicer with other applications too. Web pages that leak memory in the background are particularly likely to be killed by this mechanism and that alone is a huge improvement in overall stability.
2 comments
MayeulC 1305 days ago
I was very excited about this improvement (it was covered on phoronix IIRC), but my systems still ends up thrashing when Firefox grows too big, unfortunately.

I usually keep an eye on the memory usage I have displayed in the taskbar, and have sysrq activated in case. I tried multiple things, including avoiding swapping to disk (only using zram), and Zen kernels. I'll have to see if I use MGLRU.

link
jml7c5 1305 days ago
Do you use a userspace OOM killer, like oomd or systemd-oomd?
link
MayeulC 1299 days ago
I haven't set that up yet, though I've watched the recemt developments with interest. Another option would be to launch everything (or just Firefox) in cgroups.
link
heavyset_go 1305 days ago
Does this OOM killer direction respect cgroup memory limits? Back when I was using Firefox on a low memory system, I ran it in a limited cgroup, but features like `browser.tabs.unloadOnLowMemory` wouldn't unload tabs on low cgroup memory, but only on low total system memory.
link
gsvelto 1305 days ago
Yes it does, we've disabled tab unloading on Linux because low-memory detection just didn't work. We will re-enabled it sometimes down the line but only to avoid swap, not crashes. The OOM killer does already a good job with this change and we feel no need to do anything further (besides optimizing memory usage, but that's system-agnostic).
link