On Fri, Jun 10, 2022 at 11:25 AM Steve Langasek <steve.langa...@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/ > slanga...@ubuntu.com vor...@debian.org > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
