Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 23, 2020 12:48 am wrote:
> A cursory glance to perfmon counters on my machine shows all the software I'm running using significantly
> more commit space than the physical memory in use. This includes not only Firefox, but also Google Chrome,
> Visual Studio, Notepad++ and even Word 2019. I opened up Edge (the old one) which is a non-portable Windows-only
> application made by Microsoft and it also commits a lot more memory than it uses.

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.

> I've even tried firing up a game: Elite Dangerous. In the start screen
> it has committed 3 GiB of memory but it's only touched 1.3 GiB of it.

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.

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

> Yeah, it's pretty simple when your application makes only one allocation, in a single place
> in the code over the course of its lifetime. Real applications are different though.

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.

> And Linux' OOM killer will kill that application leaving the others running because
> it's the biggest memory hog in the system, what was the problem again?

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

> I didn't "argue" about it, I've shown hard data that proves that Windows the same
> piece of software runs into OOM conditions far more often on Windows than on any
> other platform even in the presence of significant amounts of free memory.

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.

> So where's your data proving this? Also, how exactly do you "debug" an application crashing because of an OOM?

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