Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 23, 2020 12:48 am wrote:
> Anon (no.delete@this.spam.com) on January 22, 2020 4:52 pm wrote:
> > Anyway, back to the topic, Gabriele is talking to a problem that I never see myself, so, I don't think
> > it is a problem, I have no idea what crap software is committing memory to not use, but I don't think
> > making everything overcommit will solve it, I mean, if
> > authors of that crap software realize that committing
> > isn't doing what they expect, what would prevent them from locking pages in memory?
>
> 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.
>

In case of notepad++, if you're running it for weeks (months) with more than 100 tabs, as I do, and tend to open new tabs when finishing certain work without closing previous ones, as I do, then "commit space much bigger than working set" does not mean what you say. Much more likely that memory in commit set was touched, days or weeks ago and then it was paged out to free space for a new stuff. I.e. demand paging working as intended.


> 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.
>
> So either it's all "crap software" or this is just the way
> things are on Windows. What do you think is more likely?
>
> > About the problem solved by not overcommitting I can think
> > about one pretty simple, let's say the user tries
> > to load a ridiculous big image to memory, the application will try to allocate, the OS will return no, I
> > can't, the application shows a pretty message box to the
> > user, then continue running and every other application
> > and service in the system continue it's life, nowadays this is a very rare situation, but happened during
> > Windows 95 era when it was possible to open a bitmap bigger than the total system memory.
>
> 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.
>
> > Now, let's suppose the system overcommits and allow to application to proceed, the application will
> > write one memory page at a time slowly filling up all the system memory until there is no free pages
> > left, and every other application and service start facing low memory issues, and the user won't
> > be able to open that image because his computer didn't have enough memory to start with.
>
> 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?
>
> > Gabriele asrgues that:
> > 1) Without overcommit the computer will OOM while still having physical RAM available - This never happened
> > to me and I doubt it is common at all.The existence of crap software doesn't prove it is common.
>
> 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.
>
> > 2) With overcommit OOM will be rare - With or without overcommit computer will became to slow
> > to be usable when the working set exceed the physical RAM anyway, I think that with overcommit
> > the result may be more catastrophic by not preventing the larger allocation upfront, and for
> > sure harder to debug by not having a specific allocation which triggered the OOM.
>
> So where's your data proving this? Also, how exactly do you "debug" an application crashing because of an OOM?