On Tue, Dec 22, 2020 at 12:45 PM Tom Seewald <tseewald@xxxxxxxxx> wrote: > > > If your desktop doesn't segregate apps and services into cgroups, > > systemd-oomd will kill the entire desktop whenever anything uses too > > much memory, because the desktop is going to be running in the same > > cgroup as the apps that it launches. So I think desktop spins (other > > than KDE) ought to opt out of this. It should be good for all Fedora > > editions, though (including Workstation, Server, Atomic, CoreOS), and > > also for KDE spin. > > How will this work on headless systems like Fedora Server, Atomic, and CoreOS? Will it be expected that users manually create their own cgroups? This is intended to be a generic approach to user space oom management, but it does tie into resource control too. And the resource control organization of what processes are considered critical are different between a desktop and a server. The idea of "user wants to take control or see what's going on" is a generally important goal for all of this work, regardless of the Fedora edition or spin. On the desktop, this is mainly GUI responsiveness. On Server this is probably logging, the entire network stack, and sshd - at a minimum. So those critical components. Organizing such services so that they get the minimum resources they require, no matter what resource hog happens to come along, is something that'd work out of the box. Right now the program that has the highest "badness" score gets killed off. And the badness score doesn't take its relative hit to PSI into account. That is, the program that's actually causing the worse pressure may not be the one killed off today. And that's because badness score is pretty simplistic. All things being equal, the one with the highest badness is the most recently launched program. That may not be how you want it scored even by default, you'd probably want to kill the one that's contributing the most inefficiency overall due to its behavior with respect to memory, io, and cpu consumption. I posted this to the server list the other day, but it gives a general overview of how oomd2 works in server user cases and explains a lot of the basic concepts which I think are easier to grasp for the server use case than the more complex desktop case. https://www.youtube.com/watch?v=30i7SamZxRU -- Chris Murphy _______________________________________________ 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