On Mon, Dec 21, 2020 at 11:28:45AM -0500, Ben Cotton wrote:
For memory pressure configuration, this will be
ManagedOOMMemoryPressure=kill and ManagedOOMMemoryPressureLimit=4% on
user@.service to have systemd-oomd send SIGKILLs to all processes
under a selected cgroup when total memory pressure on all tasks
exceeds 4% for 10 seconds.
For swap based actions, systemd-oomd will monitor the system-wide swap
space and act when available swap falls below the configured
threshold, starting with the cgroups with the highest swap usage to
the least. Keeping some amount of swap (if enabled) available will
prevent the kernel OOM killer from killing processes unpredictably and
spending an unbounded amount of time afterwards.
For swap configuration, this will be SwapUsedLimitPercent=90% in
oomd.conf and ManagedOOMSwap=kill on -.slice (root cgroup slice) to
have systemd-oomd send SIGKILLs to all processes under a cgroup when
swap used exceeds 90%.
One implementation approach would be to put the relevant config
in dropins (outside of the main config file), and to package them into
a separate rpm, e.g. systemd-oomd-defaults, similarly to what was done
with zram-generator-defaults.
Dropins are easier to override, and it's easy to opt-in/opt-out of the
config when that config is installable separately from the implementation.
--
Replying to the discussion in other threads, I think it makes a lot
of sense to deploy this in F34. Right now oomd works, but we don't have
a lot of feedback and there aren't really any big outstanding issues.
And without the feedback, it will not get improved. So postponing
until F35 doesn't seem to serve any particular goal.
--
Replying to the discussion in other threads, I think it's clear that
many people will need/want to opt-out. (For example it would be great if
sway would separate it's processes into .slices/.services, and I think
it'd be fairly easy to implement since there's a common ipc entrypoint
to launch things, but it's unlikely to happen for F34. Doing this will
have other advantages too, it's slowly becoming a must-have feature.)
I'm not sure how to make the opt-in/opt-out decision. Per-variant/spin/whatever
is not granular enough, because different DE and different payloads
that cut across variants need different handling. I think gnome-workstation
and the kde spins would gain most from this, so maybe could pull in
systemd-oomd-defaults from @gnome-desktop-environment and @kde-desktop-environment
groups?
Zbyszek