On Fri, Jan 03, 2020 at 02:18:40PM -0500, Ben Cotton wrote:
== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
I'll throw out another idea out here, in hope that people can provide
insight. It's something I wanted to look into for a while, but I admit
to not having done any research myself, so the approach might be totally
What about using the memory controller for user units to allocate
memory resources between the processes in the user session? Thanks to
recent developments, the gnome session uses separate systemd units
(and thus separate cgroups) for various services. We could set attributes
like memory.low for "the basic components of the user session",
and on the other hand, memory.swap.max for "the payload", i.e. various
user processes on top.
Doing something like this effectively would most likely require some
changes to how we assign processes to cgroups. I still get some processes
in "wrong" cgroups:
│ │ ├─1501571 /usr/bin/gnome-shell
│ │ ├─1501606 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth
/run/user/1000/.mutter-Xwaylandauth.SCXID0 -listen 4 -listen 5 -displayfd 6
│ │ ├─1501713 ibus-daemon --panel disable -r --xim
│ │ ├─1501718 /usr/libexec/ibus-dconf
│ │ ├─1501719 /usr/libexec/ibus-extension-gtk3
│ │ ├─1501724 /usr/libexec/ibus-x11 --kill-daemon
│ │ ├─1501980 /usr/libexec/ibus-engine-simple
│ │ ├─1503586 /usr/lib64/firefox/firefox
│ │ ├─1503691 /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser ...
│ │ ├─1503701 /usr/lib64/firefox/firefox -contentproc -childID 3 -isForBrowser ...
│ │ ├─1503747 /usr/lib64/firefox/firefox -contentproc -childID 4 -isForBrowser ...
│ │ ├─1520219 bwrap --args 35 telegram-desktop --
│ │ ├─1520229 bwrap --args 35 xdg-dbus-proxy --args=37
│ │ ├─1520230 xdg-dbus-proxy --args=37
│ │ ├─1520232 bwrap --args 35 telegram-desktop --
│ │ ├─1520233 /app/bin/Telegram --
│ │ ├─1540753 pavucontrol
(and firefox and anything-running-as-flatpak would be the prime
candidates to split out into their own cgroups and build resource
The cgroup hierarchy is mostly flat (most user services get
cgroups directly in the root of the user tree under
To make resource assignment effective, I would like to see a
"basic.slice" (name TBD) that would gather various "core" stuff like
gnome-shell-wayland.service, dbus-broker.service, and whatever
other services that the graphical session depends on. This would
get mimimum memory protections and such.
Then there should be "payload.slice", and underneath that all the
non-essential services and everything that the user starts from the
What I *don't know* is: how much of an overhead enabling the memory
controller has, and whether those resource limits would actually have
the desired effect (and more generally, how they should be best set).