systemd-oomd issues on desktop

[Aaron Rainbolt]

On Fri, Jun 10, 2022 at 5:21 AM Ernst Sjöstrand <ernstp at gmail.com> wrote:
>
> Den fre 10 juni 2022 kl 07:36 skrev Olivier Tilloy <olivier.tilloy at canonical.com>:
>>
>>
>>
>> On Fri, Jun 10, 2022 at 1:49 AM Steve Langasek <steve.langasek at ubuntu.com> wrote:
>>>
>>> On Thu, Jun 09, 2022 at 01:00:45PM -0400, Nick Rosbrook wrote:
>>> > In the reports I refer to above, applications are being killed due to
>>> > (1). In practice, the SwapUsedLimit might be too easy to reach on
>>> > Ubuntu, largely because Ubuntu provides just 1GB of swap. Since we
>>> > follow the suggestion of setting ManagedOOMSwap=kill on the root slice
>>> > [7], every cgroup is eligible for swap kill. When this condition is
>>> > met, user applications like browsers are going to be killed first.
>>>
>>> In terms of behavior that we want to see, this last sentence sets off red
>>> flags for me.  There are times when, due to memory pressure, killing
>>> processes to reclaim memory is the right answer; and it is likely that the
>>> process using the most memory on a desktop system is the browser.  But in
>>> terms of how a modern desktop is used, it's also quite likely that the
>>> browser is the most important process to the user experience on a desktop.
>>> (Cf. the Chromebook experience, where the browser effectively *is* the
>>> desktop.)
>>>
>>> I understand how we've arrived at the situation that browsers are the
>>> processes likely to be killed first when there's memory pressure; but
>>> separately from the question of what we should do for systemd-oomd overall,
>>> are there configuration changes we could make to lower the priority of the
>>> browser as a candidate for oom killing, and would those be reasonable
>>> configuration changes to make?
>>
>>
>> Also note that modern browsers (at least firefox and chrom{e,ium}) have built-in mechanisms to discard/unload tabs they consider inactive to reclaim memory, and these mechanisms are enabled by default. See about:unloads in firefox, and chrome://discards in chromium. So it really shouldn't be necessary to kill browsers the hard way.
>
>
> Yeah Firefox tracks memory pressure like this:
> https://hg.mozilla.org/mozilla-central/rev/267c8b31a3633ddfb4d7e29af56c82fc8745c0d0
>
> So systemd-oomd should trigger later than the Firefox memory pressure system.
>
> Regards
> //Ernst

This might be a silly suggestion, but it wouldn't be too hard to
implement. Why not:

1. Turn systemd-oomd off.
2. Enable the OOM killer Magic SysRq key sequence by default.
3. When the system is nearing the scary level of low memory, pop up a
message stating "You're almost out of memory. It's highly recommended
that you close some open programs immediately. If the system locks up,
press Alt+Print Screen+<whatever> to terminate a memory-hogging
application and restore functionality." (Obviously, replace <whatever>
with the proper key, I don't remember which key is used to trigger the
Magic SysRq OOM killer, but I know that's a feature.)

That would give users a heads-up before things went south, and in the
event the system ran out of memory so fast that it locked up before
the user could kill an open application, they would have the
instructions for fixing the mess, possibly still on the screen in
front of them.

Another possible solution would be to make systemd-oomd start use some
sort of timing feature to determine if the system had locked up, and
then and only then would it kill a process. Not sure how easy that is
to implement, but it would be a little less in the user's face and
less likely to kill important data.