Brendan (btrotter.delete@this.gmail.com) on January 14, 2020 12:40 pm wrote:
> You need to be more specific. For example; compare "no overcommit, with 8 GiB of RAM and 1234 TiB of swap
> space" to "with overcommit, with 8 GiB of RAM and no swap space" and see how accurate your statement is.

Windows reserves physical space for the page file and when it's system managed it rarely exceeds the size of the physical memory. If you want a 1234 TiB page file you need a 1234 TiB disk because that won't be lazily allocated. It's not like having a disproportionate page file has no cost, especially since the alternative - overcommitting - doesn't force you to pay that price.

> No. Windows doesn't overcommit and uses a page file (rather than a swap partition)
> for swap space; and will not OOM until your file system runs out of space.

You seem not to understand how Windows memory allocation works (and BTW Linux doesn't necessarily use a swap partition, it can use a swap file too). Windows memory can be mapped, you reserved a chunk of address space, committed, you requested that chunk of memory to be backed by something either physical memory or swap file, or in use which means you actually touched the memory you had previously committed. If you commit more memory than your page file + physical memory the memory allocation will fail even if you haven't touched a single byte of memory.

> Sure, these people failed to have an adequate amount of swap space.

So what about this guy?

https://crash-stats.mozilla.com/report/index/a2a937b3-4b2a-4e4c-8435-0dc6b0200108

He has 64GiB of RAM and a page file twice as large. He still has 60GiB of free physical memory but he ran out of commit space and promptly Windows started to fail memory allocations. How large do you suggest the page file needs to be in that case? How is going OOM when you still have 60GiB of free physical memory a good idea? Or a good experience for the user?