Yes, Linux Does Bad In Low RAM / Memory Pressure Situations On The Desktop

[phoronix]

Phoronix: Yes, Linux Does Bad In Low RAM / Memory Pressure Situations On The Desktop

It's been a gripe for many running Linux on low RAM systems especially is that when the Linux desktop is under memory pressure the performance can be quite brutal with the system barely being responsive. The discussion over that behavior has been reignited this week...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Does-Bad-Low-RAM

[skerit]

it will likely be months before there is an effective upstream solution

That's optimistic. Anyway, what's a few more months? It's been like this for as long as I remember.

[skeevy420]

I think that's not how the system should behave in this situation.

It's exactly how I'd expect it to behave.

A system with the memory all used up and no swap space available runs like shit...you don't say...

[Saverios]

Okay, I'll bite. What should happen when you have no more memory and no swap file and an application asks for more memory? Isn't it up to the application to handle memory unavailability gracefully?

[Danny3]

This seems to be similar to my experience with Kubuntu on a flash drive.
Very slow, lots of stalls, almost unusable.
But of course, the case is the opposite, lots of free memory (90 -95%), but KDE Plasma can't or doesn't want to use it.

[Kayote]

imho the problem here is that some of this behaviour is mirrored by GPU drivers, where memory is short

[latalante]

Never but never disable swap. Without a swap, as you can clearly see the system is not faster. It is much, much slower.
1. Always but always use a swap file in zRAM.
echo 2G > /sys/block/zram0/disksize && mkswap --label zram0 /dev/zram0 && swapon --priority 100 /dev/zram0

2. If you made this mistake and turned off swap, run resource-consuming programs with a memory limit.
systemd-run --user -p MemoryLimit=3G google-chrome

3. You can always press the emergency key combination alt-sysrq-f
An open tab in chrome will end with "Aw Snap!"

Linux works on billions of different devices, there is no one right solution how to behave in such extreme conditions, satisfying everyone.

[Space Heater]

As some of the developers mentioned, pressure stall information will likely be the best way forward. Facebook and android are using it for exactly this problem, and I think it only makes sense that mainline adopt it for OOM-detection heuristics as well.

It's a bit silly that this problem has been ignored for so long, but at least now we have a solid way of detecting this in mainline.

Other readings on psi:

https://lwn.net/Articles/759781/

https://linuxplumbersconf.org/event/2/contributions/221/attachments/45/52/02._PSI_monitor_for_memory_pressure_detection.pdf

[pomac]

The interesting part is that they are looking in to ways to dump more memory - ie things that shouldn't be prio over actual apps.

However, Linux is nicer than solaris and most (if not all) BSD:s in this case - they will all crash =)

[schmidtbag]

This is one of the very few cases where Windows works better than Linux and has for decades. There's a lot Windows is shit at, but if there's one thing it handles surprisingly well, it's running out of memory.

Okay, I'll bite. What should happen when you have no more memory and no swap file and an application asks for more memory? Isn't it up to the application to handle memory unavailability gracefully?

Crashing the high-load program is one option. The whole system is unresponsive so it's very unlikely you'll get to ever get to recover the data anyway. It's better to lose some data than to lose everything.

Though, what I'd REALLY like to see is something that triggers SIGSTOP to a process whenever it:
A. Is consuming the majority of the total used RAM.
B. The total available RAM and SWAP has exceeded 95%.
By doing this, it's a win-win: your system remains stable and usable, and you still get a chance to recover and/or SIGCONT the process. There could be a single file in the /etc folder that controls the behavior of this (so for example, maybe you want to increase the limit to 99%, or use SIGKILL instead of SIGSTOP, or ignore SWAP percentages).

Any reason why this solution couldn't be done?