Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux