Linus Torvalds (torvalds.delete@this.linux-foundation.org) on January 16, 2020 9:17 am wrote:
>
> You're talking "in my dream world, these issues wouldn't exist".

Side note: in a lot of cases, the issue isn't "OOM", it's actually "I have plenty of swap, I haven't really overcommitted anything, but the working set is so big that the machine has come to a crawl, and it's really hard to tell what is required in memory".

The fact that the GUI is "just another user space component", and easily gets paged out because it's not all that intensive (and tends to have horrible access patterns when it gets paged in again) can be another "interesting" thing from a user perspective.

The thing is, memory management is hard. It's definitely the hardest problem in any kernel. You can simplify it by making the system very inefficient - fixed-sized structures or otherwise minimizing dynamic behavior is one such way, but making limits much more conservative is another one.

Then you avoid a lot of the nasty cases, but you tend to also end up with a lot more IO and much stricter limits on what the user can do. So you might end up denying things even though they would be perfectly fine in practice, because you've partitioned your memory pool and other things might need those other parts that they aren't using now.

And yes, the Unix philosophy (and Linux took that part) has pretty much always been "give them rope". People talk about the whole "everything is a file" thing, but quite often the real philosophy is more along the lines of "let people do do what they want". Even if what they want may not be appropriate for the amount of memory they have..

It's also the "don't do that, then" philosophy of engineering.

Linus