On Tue, Dec 22, 2020 at 1:41 pm, Robbie Harwood <rharwood@xxxxxxxxxx>
wrote:
- OOM killer behavior. I think we're in agreement that this isn't the
thing that needs changed.
Let's back up. The choice is between earlyoom (status quo) or
systemd-oomd (future). We're not going to get rid of our userspace OOM
killer, because we've found a userspace killer is necessary to avoid
locking up when under memory pressure. That ship sailed when we decided
to ship earlyoom. (Well, in theory, we *could* change our minds about
that... but we should not, because earlyoom has significantly improved
our responsiveness under low memory conditions.) earlyoom was always
recognized as a stopgap measure until systemd was ready to take over.
- Enabling swap. Swap is really slow (by virtue of not being RAM...)
and we don't seem willing to acknowledge that. If we want the system
to be snappy and responsive... we shouldn't be swapping.
- Swap aggressiveness. Suggested by above, people want swap anyway.
(Sometimes it's for hibernation (not supported, but that stops no
one), sometimes it's for... historical reasons? Underprovisioning?)
This could be tuned to the use cases we actually want.
- Education. Get people to a point where admins don't deploy swap on
systems that aren't going to hibernate. I'll readily admit this one
might be hardest.
And even possibly the (conceptually) simplest solution of all:
- Swap usage monitoring as described for oomd... but in the kernel.
This saves you on all the overhead of running in userspace, if
nothing
else.
I don't think we need to be discussing swap at all. Any amount of swap
means you won't have good performance under memory pressure. We don't
create a disk-based swap partition by default anymore, and swap on zram
is relatively fast, so there's no reason to consider swap as part of
this discussion. We are discussing defaults, after all. If you're going
to use a non-default configuration, that's fine of course, but it
shouldn't affect our decisions on how Fedora should work by default.
Michael
_______________________________________________
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