systemd-oomd issues on desktop

[Lukas Märdian]

Am 10.06.22 um 12:17 schrieb Sebastien Bacher:
> Le 10/06/2022 à 11:40, Julian Andres Klode a écrit :
>> 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.
> 
> It might be working 'correctly' but is not perceived as such by users. 
> I've seen regular complains from users since the release stating that 
> their browser or code editor got closed in front on them without 
> warning, on a machine they had been using for years with the same 
> configuration and software without issue.
> 
> They might be getting short in resources but in practice they never 
> experienced a sluggish system due to it and just see the feature as buggy.

I agree with Julian in that systemd-oomd in general seems to be working 
as expected. Its purpose is all about jumping in _before_ a system 
reaches its point of no return and unresponsive swapping death.

Therefore, I feel like we should not increase the recommended 
"SwapUsedLimit=90%" default much higher, i.e. option (1), as that could 
lead to situations where it's already too late to clear some memory and 
thus defeat the purpose of having sd-oomd.


OTOH, receiving those bug reports shows that sd-oomd is not yet properly 
optimized either, killing people's "important" applications first (such 
as the browser). Especially, if the browser applies some memory 
monitoring on its own to discard/unload unused tabs and free up memory, 
as suggested by Olivier.


The option (3) recommended by Nick, could be one viable option in the 
Ubuntu context (only 1G swap available) for the time being, until we can 
have a proper upstream solution (using notifications and hooks) [1]. 
Thanks for bringing this up with the upstream developers, Michel!

I wonder if we could use a more selective approach, though, using 
"OOMScoreAdjust=" in the systemd.exec environment (i.e. Gnome-Shell 
launcher in Ubuntu's context, as sd-oomd is currently only enabled on 
Ubuntu Desktop) [2], to reduce the probability of certain "important" 
apps being killed first, e.g. by maintaining an allow-list of such apps.

Of course we do not want to introduce different classes of apps 
randomly, but would need to come up with a proper policy of which apps 
would be eligible to have a lower "OOMScoreAdjust" value. I feel like 
having individual mechanisms on the application layer to keep memory 
consumption under control, such as a browser's tab unloading, could be a 
fair eligibility criteria.

Cheers,
   Lukas

[1] https://github.com/systemd/systemd/issues/23606
[2] 
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=