<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Den fre 10 juni 2022 kl 07:36 skrev Olivier Tilloy <<a href="mailto:olivier.tilloy@canonical.com">olivier.tilloy@canonical.com</a>>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div><div dir="ltr" class="gmail_attr">On Fri, Jun 10, 2022 at 1:49 AM Steve Langasek <<a href="mailto:steve.langasek@ubuntu.com" target="_blank">steve.langasek@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jun 09, 2022 at 01:00:45PM -0400, Nick Rosbrook wrote:<br>
> In the reports I refer to above, applications are being killed due to<br>
> (1). In practice, the SwapUsedLimit might be too easy to reach on<br>
> Ubuntu, largely because Ubuntu provides just 1GB of swap. Since we<br>
> follow the suggestion of setting ManagedOOMSwap=kill on the root slice<br>
> [7], every cgroup is eligible for swap kill. When this condition is<br>
> met, user applications like browsers are going to be killed first.<br>
<br>
In terms of behavior that we want to see, this last sentence sets off red<br>
flags for me.  There are times when, due to memory pressure, killing<br>
processes to reclaim memory is the right answer; and it is likely that the<br>
process using the most memory on a desktop system is the browser.  But in<br>
terms of how a modern desktop is used, it's also quite likely that the<br>
browser is the most important process to the user experience on a desktop. <br>
(Cf. the Chromebook experience, where the browser effectively *is* the<br>
desktop.)<br>
<br>
I understand how we've arrived at the situation that browsers are the<br>
processes likely to be killed first when there's memory pressure; but<br>
separately from the question of what we should do for systemd-oomd overall,<br>
are there configuration changes we could make to lower the priority of the<br>
browser as a candidate for oom killing, and would those be reasonable<br>
configuration changes to make?<br></blockquote><div><br></div><div>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. </div></div></div></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Yeah Firefox tracks memory pressure like this:</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><a href="https://hg.mozilla.org/mozilla-central/rev/267c8b31a3633ddfb4d7e29af56c82fc8745c0d0">https://hg.mozilla.org/mozilla-central/rev/267c8b31a3633ddfb4d7e29af56c82fc8745c0d0</a></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">So systemd-oomd should trigger later than the Firefox memory pressure system.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Regards</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">//Ernst<br></div></div></div>