systemd-oomd issues on desktop

[Dan Streetman]

On Fri, Jun 10, 2022 at 11:25 AM Steve Langasek
<steve.langasek at ubuntu.com> wrote:
>
> On Fri, Jun 10, 2022 at 11:40:52AM +0200, Julian Andres Klode wrote:
> > On Thu, Jun 09, 2022 at 03:19:36PM -0400, Dan Streetman wrote:
>
> > > > I think that either option (1) or (3) would be the most reasonable --
> > > > maybe trying (1) first and falling back to (3) if necessary. If anyone
> > > > has an opinion on this, or can think of other options, I would
> > > > appreciate the input.
>
> > > Was systemd-oomd enabled by default for a specific reason? The kernel
> > > is quite able to handle oom situations itself, and has been for years,
> > > so while I'm not trying to suggest systemd-oomd is without any use
> > > case, I'm skeptical that systemd-oomd should be enabled *by default*.
> > > I think it's more likely to behave better when enabled to address a
> > > specific system use case, and leave the default behavior of handling
> > > oom to the kernel.
>
> > No what the kernel does is it starts stuttering, the system becomes
> > unresponsive and eventually needs a hard reset maybe.
>
> > The bug reports we see show that systemd-oomd is working correctly:
> > The browser gets killed, the system remains responsive without having
> > become unresponsive as would be the usual case.
>
> If systemd-oomd is killing in-use processes before the user is bothered by
> the sluggishness, then it's not working correctly.
>
> It's difficult to ensure the oom killer is working "correctly" given such a
> soft definition, but I agree that the increase in user complaints on 22.04
> indicate we haven't found the right balance yet.

I haven't looked at the details of how systemd-oomd works, exactly,
nor what the default config is, but I'd suggest the foundations team
take a close look at it from a perspective of what issue you want to
'fix' - if that issue is avoiding 'swap hell', then look at
systemd-oomd from the perspective of being able to detect high (and
'high' is a subjective term that will differ across systems),
sustained (another subjective term) swap reads and writes (and even
then, it's not always as simple as 'application X is causing heavy
swapping'). If the issue is avoiding actual ENOMEM errors, look at
systemd-oomd from the perspective of total free system memory (e.g. is
the system in direct reclaim?).

I have absolutely no doubt that systemd-oomd is better suited than the
kernel to handling oom conditions, when systemd-oomd is configured
properly for the system workload; I'm much more skeptical that
systemd-oomd can be generically configured to handle detecting "out of
memory" for any system workload if configured with generic defaults.

>
> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                   https://www.debian.org/
> slangasek at ubuntu.com                                     vorlon at debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel