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

[tuxd3v]

The behavior being described here sounds like a bug that is being exposed in a low RAM condition; if both main memory and the swap file is full/disabled, why is the OS locking up performing I/O to the HDD? That sounds like a separate problem then what most people are talking about here right now. I think the obvious thing to check is what the OS is attempting to do in this condition, because it doesn't sound correct to me.

Could be a Bug, or not..
if swap is been used, you will have IO on the disk( there are other processes running, and swap out/in takes IO to the roof )..

[aksdb]

This doesn't make any sense. If you run out of memory and don't have a swap file I'm surprised the system runs at all. I sincerely don't understand the complaint.

For goodness sake, just create a swap file and you'll be fine. Of course it won't run as fast as it would with more memory, but I know from many years of experience with low memory systems in the old days that the performance is more than acceptable.

You wish. With a swap file a memory leaking (or hogging) application will then simply start to put pressure on disks aka I/O, which also slows the system down to a halt. At least from a user perspective.

[atomsymbol]

That was literally the point of the IMHO part of my post you quoted. I don't understand how you can have such an obviously high level of education with no reading comprehension.

Ok. Let's retrace the steps from the beginning, maybe it will resolve some issues in our communication:

1. You read (past tense) https://lkml.org/lkml/2019/8/4/15 which contains the text "I think that's not how the system should behave in this situation"
2. You responded with "It's exactly how I'd expect it to behave"
3. I replied with "This is interpreting serious unsolved operating system deficiencies as positive features of the operating system"
4. You wrote "In this case they removed a safe guard and pushed it beyond its limit"
   1. I believe they didn't remove any safeguard. Which safeguard do you believe they removed? Enabling swap only postpones it to a later time, the end result (unusable system) being the same.
   2. If the working set of running applications exceeds the size of system memory, any large amount of swap space on HDD/SSD is unable to prevent a significant system slowdown (unless the swap is located on something like 3D XPoint memory, but still the cost of copying pages from/to such a device is unavoidable and can result in slowdowns in certain scenarios).
5. You wrote "No matter how many safe guards are in place, it doesn't help it if a user pushes something beyond its limits"
   1. It seems to me that the first part of the sentence is contradicting the second part. If safe guards are in place, it is impossible for the user the push the system beyond its limits.
6. You wrote "How is the kernel supposed to know if it needs to halt Plasma, Firefox, ...? All it can do is juggle stuff with what little resources it has available" and "IMHO, this is really a problem that should be solved by a daemon"
   1. It is true that solution to OOM issues can be in user-space and/or/xor in kernel-space. However, it seems to me that a partially-kernel-based solution is more deterministic and less likely to fail than a user-space daemon with no assistance from the kernel. The only entity on the machine that precisely knows whether free memory is available or not available is the Linux kernel (Linux kernel is a monolithic kernel, not a microkernel).

[carewolf]

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...

I expect it to RECOVER.. The problem is that Linux doesn't recover after the overcommit of memory passes. The fact that you need to run "swapoff -a; swapon -a" to recover is the problem, combined with that swapoff -a runs ~100 times slower than it should considering the available SSD disk-speed.

[elatllat]

...
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
...

> systemd-run --user -p MemoryLimit=100M chromium-browser

> ps -e -o rss,comm --sort -rss | grep chrom
433840 chromium-browse
400108 chromium-browse
227212 chromium-browse
191332 chromium-browse
182840 chromium-browse
139124 chromium-browse
120764 chromium-browse
96780 chromium-browse
89604 chromium-browse
74584 chromium-browse
72324 chromium-browse
47516 chromium-browse
42988 chromium-browse
12476 chromium-browse

[skeevy420]

Ok. Let's retrace the steps from the beginning, maybe it will resolve some issues in our communication:

1. You read (past tense) https://lkml.org/lkml/2019/8/4/15 which contains the text "I think that's not how the system should behave in this situation"
2. You responded with "It's exactly how I'd expect it to behave"
3. I replied with "This is interpreting serious unsolved operating system deficiencies as positive features of the operating system"
4. You wrote "In this case they removed a safe guard and pushed it beyond its limit"
   1. I believe they didn't remove any safeguard. Which safeguard do you believe they removed? Enabling swap only postpones it to a later time, the end result (unusable system) being the same.
   2. If the working set of running applications exceeds the size of system memory, any large amount of swap space on HDD/SSD is unable to prevent a significant system slowdown (unless the swap is located on something like 3D XPoint memory, but still the cost of copying pages from/to such a device is unavoidable and can result in slowdowns in certain scenarios).
5. You wrote "No matter how many safe guards are in place, it doesn't help it if a user pushes something beyond its limits"
   1. It seems to me that the first part of the sentence is contradicting the second part. If safe guards are in place, it is impossible for the user the push the system beyond its limits.
6. You wrote "How is the kernel supposed to know if it needs to halt Plasma, Firefox, ...? All it can do is juggle stuff with what little resources it has available" and "IMHO, this is really a problem that should be solved by a daemon"
   1. It is true that solution to OOM issues can be in user-space and/or/xor in kernel-space. However, it seems to me that a partially-kernel-based solution is more deterministic and less likely to fail than a user-space daemon with no assistance from the kernel. The only entity on the machine that precisely knows whether free memory is available or not available is the Linux kernel (Linux kernel is a monolithic kernel, not a microkernel).

Do you not know any stupid people? They're why we have safeguards in the first place.

You think you have it all nice and safe and working good. Nope, nope, nope. Some stupid motherf*cker will come along any minute and teach you three new dangers you never even considered because why would someone be that f*cking stupid; but they are that stupid. They are that stupid.

A safeguard is like a safety on a gun. There's a good chance you'll shoot yourself in the foot if you're stupid and play with the gun like it's a toy.

[aksdb]

Do you not know any stupid people? They're why we have safeguards in the first place.

You think you have it all nice and safe and working good. Nope, nope, nope. Some stupid motherf*cker will come along any minute and teach you three new dangers you never even considered because why would someone be that f*cking stupid; but they are that stupid. They are that stupid.

A safeguard is like a safety on a gun. There's a good chance you'll shoot yourself in the foot if you're stupid and play with the gun like it's a toy.

But the way Linux currently behaves in regards to OOM is basically like a loaded gun without safety on the counter of a supermarket.

[latalante]

> systemd-run --user -p MemoryLimit=100M chromium-browser

> ps -e -o rss,comm --sort -rss | grep chrom
433840 chromium-browse
400108 chromium-browse
227212 chromium-browse
191332 chromium-browse
182840 chromium-browse
139124 chromium-browse
120764 chromium-browse
96780 chromium-browse
89604 chromium-browse
74584 chromium-browse
72324 chromium-browse
47516 chromium-browse
42988 chromium-browse
12476 chromium-browse

I'm not sure but it works only with cgroup v2 (systemd.unified_cgroup_hierarchy=1).
https://github.com/systemd/systemd/issues/10581

Maybe try it

sudo systemd-run -p MemoryMax=512M /usr/bin/sudo -u $username env DISPLAY=:0 google-chrome --user-data-dir=/tmp/chrome
systemctl show run-r5fdff4a5a5864f47bebf05bb6b233007.service
systemctl status run-r5fdff4a5a5864f47bebf05bb6b233007.service

Maybe better to use --uid= and --gid= with sudo systemd-run. Check.

sudo systemd-run -t -p MemoryMax=512M --uid=1000 --gid=100 env DISPLAY=:0 google-chrome --user-data-dir=/tmp/chrome

cat /usr/lib/systemd/system/user\@.service

...
Delegate=pids memory
...

[starshipeleven]

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...

You are a moron.

A system with memory used up and no swap available is supposed to run the OOM killer to "sacrifice children" (actual error message it prints in the dmesg), killing non-critical processes to stay functional and responsive, so that someone can actually do something about it.

I can't go in and fix shit if the GUI does not work, or if SSH is unresponsive.

On anything remotely new I always had to run without swap partition to have the OOM killer wake up and do its job, if I leave swap the system will start swapping like crazy and lock down everything even on a SSD.

[elatllat]

...only with cgroup v2...

> mount | grep -c cgroup/memory
1

...

sudo systemd-run -p MemoryMax=512M /usr/bin/sudo -u $username env DISPLAY=:0 google-chrome --user-data-dir=/tmp/chrome...

> sudo systemd-run -p MemoryMax=512M /usr/bin/sudo -u $USER env DISPLAY=:0 chromium-browser --user-data-dir=/home/$USER/.config/chromium/

> group_mem.sh chrom
1,045 MB chromium-browse

> systemctl show run-r4c138899383242ad9f92331b51d24c41.service | grep -i Memory
MemoryCurrent=[not set]
MemoryAccounting=no
MemoryLow=0
MemoryHigh=infinity
MemoryMax=536870912
MemorySwapMax=infinity
MemoryLimit=infinity
MemoryDenyWriteExecute=no

Maybe you should try before you recommend.
I think I'll try cgroup_enable/cgcreate/cgexec next