systemd-oomd issues on desktop
Julian Andres Klode
julian.klode at canonical.com
Fri Jun 10 15:52:59 UTC 2022
On Fri, Jun 10, 2022 at 08:24:41AM -0700, Steve Langasek 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.
If the user is bothered by memory usage and swapping death, then we
might already be in the point of no return territory and it's too
late to be able to kill stuff.
>
> 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.
It surely is annoying if stuff gets killed, but I think the main
problem is that there is no desktop integration telling the user
why something was killed so they assume malfunction.
If we had a popup after an oom event saying
The application firefox was closed to maintain system performance
we'd have a lot less complaints.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220610/49775514/attachment.sig>
More information about the ubuntu-devel
mailing list