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!
I should really send a patch rather than complaining ...
$ 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. systemd-run --user --scope --unit=ff-$$.scope \
-p MemoryMax=4G -p MemoryHigh=3G \
-p MemorySwapMax=0 \
firejail firefox "$@"cgroups v1 has a pretty nice API but it requires root. V2 does not require root but it’s a lot coarser and not as simple or reliable: https://unix.stackexchange.com/questions/753929/receive-a-me...
It would also logically be sent to “every” process on the machine, with the subsystem probably having a heuristic to skip processes which were already signaled and have not had significant memory increases since. The goal of an early warning is to cooperatively release memory (and maybe abort memory intensive computations), the kernel already kills processes “at random”, it does not need a second way to do that.