4 ms·

I looked into this, and actually, it seems like maybe you can? https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj.5.html https://man7.org/linux/man-pa

I looked into this, and actually, it seems like maybe you can? https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj.5.html https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj... So, in actuality, I think your assertion just taught us all something, because despite knowing that the OOM killer and that the Magic SysRq key[1] exists, I didn't know you could configure this as an input! [1]: https://en.wikipedia.org/wiki/Magic_SysRq_key https://en.wikipedia.org/wiki/Magic_SysRq_key

rwmj 5mo ago
I'm aware of it, but it's awkward to use in practice. You have to track down all the FF processes, each time you run it, and adjust all their scores.
- loeg 5mo ago
  Maybe firefox could self-adjust, as a policy?
  - rwmj 5mo ago
    Yes this would be nice. Or maybe the OOM system would have two other files, /sys/oom/kill_first and /sys/oom/kill_never which would solve the problem more directly for the majority of cases. I should really send a patch rather than complaining ...
  - pavon 5mo ago
    It looks like it does, which depending on your goal is either helpful or part of the problem. By default processes should inherit their parent's oom_score_adj. If I exit out of firefox completely, then start it up (with no saved tabs), this is the behavior I see: $ firefox-esr& PID=$!; choom -p $PID -n 42 [1] 105360 pid 105360's OOM score adjust value changed from 0 to 42 $ for p in $(ps --ppid $PID -opid --no-headers $PID); do printf "%3d" $(</proc/$p/oom_score_adj); ps -opid,comm --no-headers $p; done 0 105360 firefox-esr 0 105425 Socket Process 167 105451 Privileged Cont 0 105456 RDD Process 100 105495 WebExtensions 0 105524 Utility Process 233 105534 Web Content 233 105542 Web Content 233 105549 Web Content See how each firefox process has a different oom_score_adj with Web Content being more likely to be killed than other processes (233), and none of them have the value that the process was started with (42). This is Firefox 140.11 ESR running on Debian 13.
    - loeg 5mo ago
      Nice!
- nick__m 5mo ago
  You could launch it as a systemd user target with OOMScoreAdjust=500 in the service section; weird and unconventional but wrapped in .desktop file it doesn't appear to be unwieldy.
- jitl 5mo ago
  sounds like a job for a program
- bellowsgulch 5mo ago
  Ah. Yes, that is awkward. Well, nonetheless, you taught me a new feature. Thanks!

rwmj 5mo ago

I'm aware of it, but it's awkward to use in practice. You have to track down all the FF processes, each time you run it, and adjust all their scores.

loeg 5mo ago
Maybe firefox could self-adjust, as a policy?
- rwmj 5mo ago
  Yes this would be nice. Or maybe the OOM system would have two other files, /sys/oom/kill_first and /sys/oom/kill_never which would solve the problem more directly for the majority of cases. I should really send a patch rather than complaining ...
- pavon 5mo ago
  It looks like it does, which depending on your goal is either helpful or part of the problem. By default processes should inherit their parent's oom_score_adj. If I exit out of firefox completely, then start it up (with no saved tabs), this is the behavior I see: $ firefox-esr& PID=$!; choom -p $PID -n 42 [1] 105360 pid 105360's OOM score adjust value changed from 0 to 42 $ for p in $(ps --ppid $PID -opid --no-headers $PID); do printf "%3d" $(</proc/$p/oom_score_adj); ps -opid,comm --no-headers $p; done 0 105360 firefox-esr 0 105425 Socket Process 167 105451 Privileged Cont 0 105456 RDD Process 100 105495 WebExtensions 0 105524 Utility Process 233 105534 Web Content 233 105542 Web Content 233 105549 Web Content See how each firefox process has a different oom_score_adj with Web Content being more likely to be killed than other processes (233), and none of them have the value that the process was started with (42). This is Firefox 140.11 ESR running on Debian 13.
  - loeg 5mo ago
    Nice!
nick__m 5mo ago
You could launch it as a systemd user target with OOMScoreAdjust=500 in the service section; weird and unconventional but wrapped in .desktop file it doesn't appear to be unwieldy.
jitl 5mo ago
sounds like a job for a program
bellowsgulch 5mo ago
Ah. Yes, that is awkward. Well, nonetheless, you taught me a new feature. Thanks!