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 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




[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