Anon (no.delete@this.spam.com) on January 23, 2020 5:02 pm wrote:
> How much is "significantly" for you? In my company PC Notepad++ open with 12MB private working set
> and 16MB commit size, if we add the shared working set the total working set will be actually bigger
> than the commit size, which is expected since the memory is shared with other processes.
>
> All but 3 process have about the same ratio between commit size, private working
> set and total working set, at least by my definition of "significantly".
>
> The 3 processes with different ratio are MariaDB, Avast and Dell Support assistant, the last two I only
> have because the PC is not mine, both with 500MB commit size, the first I only have installed because
> software of the company require it, and takes 1.5GB commit size, all the 3 fits my definition of "crap
> software" and that's not just because of their memory usage pattern, in fact, I don't even care about
> their memory usage pattern because 2.5GB commit size is not a problem for the large page file.

Yeah, that's how it is on Windows. And that's why OOM crashes are more common on Windows than on platforms with overcommit.

> I don't have this game, but it is not a surprise for me if games preallocate memory, I'd rather
> receive a message "out of memory" when opening the game than crashing due to OOM in the middle
> of a match, I would be very pissed of if the OS killed the game in the middle of a match.

If I actually go past the start screen the game the memory consumption goes up quite a bit (and the committed space too), so no, it's not preallocating stuff in order not to fail later.

> I wonder, how softhouses that ported games to Linux deal with the OOM
> killer other than "I told you the minimum requirement was 4GB".

Given identical configuration they will have less OOM crashes.

> Yet, algorithms with a predictable memory usage do exists, on any of them the programmer can allocate
> before starting and return "sorry, can't do that" if the allocation fail, and the program can even choose
> a less memory hungry algorithm to continue of inform the user he must choose a smaller dataset.

Could you point to an actual application that does that? Your claim that they exist isn't enough to convince me they actually do.

> After the user spent precious time on a task the machine wouldn't be able to complete.

The same would have happened on Windows, what was the point again?

> It was what, 38% of OOM where still had free physical memory? so 62% was because the user had
> a very low end machine (that rarely ships with Linux) that actually run out of memory.

No, the second biggest cause is 32-bit users running out of virtual address space (usually due to fragmentation). The amount of users that run out of commit-space in a scenario where physical memory is also low is fairly small portion of the total.

> By looking at the stack trace which will tell exactly which line of code failed to allocate memory.

And what will you do about that? Fix it? Do you realize how silly it sounds? It might not even be your fault, it might be some other applications' fault. You don't debug OOM crashes unless they're leaks, and to detect leaks you need far more than a stack trace of the first allocation that failed.

The only thing you can do with stack traces of failures is - given that one specific trace comes up often enough - see if it's possible to make the allocation fallible and deal with the failure. Though there's usually not many places where you can do that and the extra complexity is often not worth the fuss because now you have to test the failure path too or hope nobody breaks it and introduce a worse type of crash.