Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

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

 



On Thu, Jan 9, 2020 at 5:58 AM Benjamin Berg <bberg@xxxxxxxxxx> wrote:
>
> On Wed, 2020-01-08 at 12:24 -0700, Chris Murphy wrote:
> > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
> > > - facebook is working on making oomd something that just works for
> > >   everyone, they are in the final rounds of canonicalizing the
> > >   configuration so that it can just work for all workloads without
> > >   tuning. The last bits for this to be deployable are currently being
> > >   done on the kernel side ("iocost"), when that's in, they'll submit
> > >   oomd (or simplified parts of it) to systemd, so that it's just there
> > >   and works. It's their expressive intention to make this something
> > >   that also works for desktop stuff and requires no further
> > >   tuning. they also will do the systemd work necessary. time frame:
> > >   half a year, maybe one year, but no guarantees.
> >
> > Looks like PSI based oom killing doesn't work without swap. Therefore
> > oomd can't be considered a universal solution. Quite a lot of
> > developers have workstations with quite a decent amount of RAM,
> > ~64GiB, and do not use swap at all. Server baremetal are likewise
> > mixed, depending on workloads, and in cloud it's rare for swap to
> > exist.
> >
> > https://github.com/facebookincubator/oomd/issues/80
> >
> > We think earlyoom can be adjusted to work well for both the swap and
> > no swap use cases.
>
> But so can oomd, after all, they are willing to implement a plugin that
> uses the MaxAvailable heuristic. It just won't be available in the
> short term.
>
> In principle, I think what we are trying to achieve here is to keep the
> system mostly responsive from a user perspective. This seems to imply
> keeping pages in main memory that belong to "important" processes.

Right, not merely clobbering a process the user ostensibly wants to
run and complete. The just don't want it to take over.


> Should oomd not manage to do this well enough out of the box, then I
> see two main methods we have to improve things:
>
>  * Aggressively kill when we think important pages might get evicted
>    - earlyoom does this based on MemAvailable
>    - oomd plugin could do the same if deemed the right thing
>  * Actively protect important processes[1]:
>    - set MemoryMin, MemoryLow on important units
>    - limit "normal" processes more e.g. MemoryHigh for applications
>    - in the long run: adjust the OOMScore/MemoryHigh dynamically based
>      on whether the user is interacting with an application at the time
>
> earlyoom does the first and has the big advantage that it can be
> shipped in F32. However, it is not clear to me that this aggressive
> heuristic is actually better overall. And even if it is, we would
> likely still move it into oomd in the long run.

I agree, although the decisions made in this release cycle can really
only be made based on what we know now. Earlyoom has a chance of
making this a better experience in the case where something really
should be OOM killed, just sooner than the kernel's oom-killer would
have. It doesn't solve the unresponsiveness problem that happens once
RAM is full, but before swap reaches 10%. In any case, it's not going
on a process kill spree. It's not going to magically free up a system
every time its under swap duress.

I've got cases where a system is under significant duress with only
50% swap use - earlyoom does nothing for that.

>
> Finally, for F32 we might already be able to improve things quite a lot
> simply by setting a few configuration options in GNOME systemd units.

Maybe. What are the risks? Is it fair to characterize this as more of
optimization of existing functionality, than it is a feature? That's a
technical question. Of course, if this improves responsivity of the
system while under swap thrashing, it's definitely a marketable
feature!

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