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

[k1e0x]

It does crap out and crash, FreeBSD is crap compared to Linux in low memory situations

Mmmm well apparently not as bad as Linux. haha.

But no actually I don't have that machine anymore. (thank god 4gigs?) but what would happen on FreeBSD 12 is (usually) either gnome or chrome would just vanish, the mouse wouldn't even stutter.. the app was just gone. I was left going.. "what where did it go...? ooooh right.. oom killer".. need to keep fewer tabs open. If gnome-shell died it would relaunch or gdm would pop up. Occasionally it would kill something important tho.. so ymmv it's not a good situation in any case.

[birdie]

Why not use the excellent earlyoom project? It's a user-space highly configurable memory killer designed for the desktop use-case.
I've tested it and it's good.

meanwhile I run raspbian on a Pi 0 with 0.5gb ram, GUI & chrChrom and it shows little problems. 32 bit kernel is better maybe?

I've just installed it ;-)

The issue we are arguing about is that (some of) its functionality must be built into the kernel itself to avoid complete stalls for up to hours.

[F.Ultra]

Mobile OSes don't behave this way.

They also mostly only run a single application at a time

[down1]

They also mostly only run a single application at a time

Yes and isn't every application designed to gracefully exit at any time? This is not a viable model for server applications and scientific computing.

[F.Ultra]

I think M@yeulC and elatllat are on to something. There should be a signal that tells the application to release some of its memory when the system is low on memory. The application knows what it needs to have on memory and what it can get rid of.

The number of applications that could actually do some housecleaning in a low mem situation are probably in a single digit range. The few that can are the ones that use RAM as a cache like a DB (e.g MySQL) or a web browser, both of which would probably work better if they simply let the kernel do the caching anyway (with memory mapped files and the like) instead of building their own cache-system (something they often do in order to work on other operating systems).

Another problem with such a signal would be for those applications that would want to flush their RAM content to disk in a low mem situation, in order to do that they would need to allocate even more memory (open a file, having a write buffer and so on).

[F.Ultra]

Yes and isn't every application designed to gracefully exit at any time? This is not a viable model for server applications and scientific computing.

AFAIK in Android the JVM can simply halt the application and flush it to disk, then later it can read it back and resume operation. Something that is not a problem for a majority of apps but would be quite problematic for say a network server...

[Slartifartblast]

this has been an issue with linux desktop for the past several years. it use to be that you could run linux on a quarter gig of ram with no risk of issue for most average tasks..

Parkinson's Law

[Spazturtle]

Swap only delays this issue, you will run into the same problems when the Swap gets compltely filled up.

[timrichardson]

I've just installed it ;-)

The issue we are arguing about is that (some of) its functionality must be built into the kernel itself to avoid complete stalls for up to hours.

OOM killing is hard to generalise, and the memory pressure indicators are hard to interpret. Not only is earlyoom likely to be the fix that desktop users are looking for, it will be an early adopter of PSI stats once someone works how to use them in the general case, so that's another reason to follow it. Meanwhile, the discussion around the project is more more informed. It is astounding that so few people know about it. I could understand if people reported that it didn't work, but actual knowledge of the tool seems close to zero. https://github.com/rfjakob/earlyoom
I tried killing a 4GB VM ... it is not too hard to get the kernel to deal badly with the situation. I could not kill the same machine when earlyoom was running. swap made no difference either way, of course; swap advocates are barking up the wrong tree if they think swap settings can save the kernel's OOM reaction.

[Volta]

There should be userspace daemon for this like in Android. However, "desktop" part of Linux is busy with removing features and braking userspace all the time. It amazes me how Linux kernel developers care about not breaking compatibility while "desktop" does it every time. I hope Valve comes with sane distribution and ends this madness.