Comment 10 for bug 2006070

Ok, somewhat good news. I have been watching the memory usage on the machine as many applications start / stop , and am tracking the growth and management.

A tool to tweak the behavior ---
One system parameter I had tweaked before reporting this issue was vm.swappiness , I had moved this down to 30, mostly because I'd like to get the best performance, while avoiding the use of swap space. it had the intened effect, while using almost all available memory - generally a good thing (why have all this memory if you're not using it, right?).

Now, i've moved this back up to 60 (which I believe is the default for the kernel options). In response I am seeing better free-memory management from the kernel. The downside is that I am absolutely seeing lower performance on and across web-pages and other applications as swap is used a bit more. The difference is measured in fractions of a second, I could measure the difference but I'm not sure if this audience would like to see those details (let me know if this is interesting).

For those at home -- edit: /etc/sysctl.conf , modify or add the parameter 'vm.swappiness = 60' and then on your terminal run 'sysctl -p'.

I mention this on this bug thread because this parameter directly effects the OOM killer behavior because the OOM killer appears to be swapiness un-aware, and this is also the underlying behavior modifier for the Chrome threads, and the Flatpak or gnome-software threads as they grow in size. I will continue to monitor for gnome-software threads and memory usage, but this means the heavier memory usage is effectively hidden by worse offenders (chrome likely being one of the heaviest users for us all).

On Chrome --
Since Chrome is doing so much lately to manage their own threads, I hope this kerenel tuning parameter is kept in mind for memory management, it could save the team a lot of time building their own memory management utility/toolchain. There might even be some kind of alert / capability for the kernel to respond differently to certain applications depending on how aggressive they would like their own userspace managed. (Kerenel development feature!)

One gnome-software --
I will keep tabs on the Flatpak memory usage. In the mean time I have disabled snapd entirely. I don't wish to manage my applications like this. Apt is about as far as I want to go now, the interactions of many different pakage managers adds a lot of complexity. I want to incentivize application develoeprs to use as few packaging systems as possible. It's getting quite bad out there - there's are now whole businesses that have sprung up to convert the same binaries into different packaging formats and their dependencies. It's really got to stop, it's such a waste of time and resources to 're-invent the wheel'.

On the root cause --
I would much prefer that we encourage developers to build statically compiled binaries, rather than build containers upon containers to manage what I see as effectively a problem stemming from resource sharing linked to library (mis)management.

I hope this is helpful to development here and across kernel development. I will continue to provide meaningful feedback as much as possible.