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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
