On Mon, Dec 28, 2020 at 07:44:04PM -0000, Tom Seewald wrote: > > On Tue, Dec 22, 2020 at 6:17 PM Anita Zhang <anitazha(a)fedoraproject.org> wrote: > > > > > > Another variation on this theme: enable by default in Fedora 34 Server > > edition. And more broadly rolled out for Fedora 35. > > > > If it's broadly ready for Fedora 34, great. Otherwise, it seems like a > > good fit for Fedora Server edition, given sd-oomd's server origin and > > oomd2 been used in production for a number of years. It'd be a > > significant headline feature for Server edition, especially fitting > > for the in-progress reboot of that project. Any thoughts from Server > > WG folks? > > I don't think enabling systemd-oomd for Fedora server by default makes a lot of sense right now. Why would we want to automatically enable systemd-oomd in cases where users either have to manually manage cgroups or risk a worse experience than what currently exists with earlyoom? If a user is already creating/managing cgroups themselves, then manually enabling systemd-oomd would be a minor extra step. But if the user isn't managing cgroups (which I believe is the common case), then that user would be pretty surprised if systemd-oomd wipes out a huge swath of running programs that happen to be in the same cgroup. > > With Gnome and KDE Plasma most of the cgroup creation is done automatically, so it makes more sense to enable systemd-oomd by default as those systems are already set up for systemd-oomd to work well. I'm a bit unclear on this and perhaps the change owners could comment: This operates on slices right? So in a server context each service is in it's own slice. So, while it might kill say a httpd slice, other services would be fine? That doesn't seem great if you are running a deadicated webserver, but perhaps not so bad if you are running a bunch of different services. Also, perhaps there's some way to teach the web server applications to put say different wsgi applications in different slices, but no idea if any work has gone into that. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
