How can this process' virtual memory be bigger than Physical memory + Swap?
It's my understanding that, in this example,
docker's daemon has requested 1114MB of memory from the OS, assigning a section of virtual address space to it, yet physical memory isn't used until the process actually requires it. That's fine.
However, how can the OS say "sure, here's your 1.1GB" when it couldn't ever fulfill that request? Shouldn't
malloc() (or whatever
docker is using) fail immediately?
If it's actually "overselling" memory space, what's the point of the return value of
No rational OS would allow you to allocate virtual memory without having page space to back it up. Sadly, there are OS's that are not rational (or have system parameters that enable such irrational behavior). Your OS might allow your malloc call to successfully map pages to memory then fail when you try to access the memory. It makes debugging a nightmare. Some systems refer to this as "overcommitment." Note that this term is often used for entirely different purpose in OS terminology.
As @user3344003 said, this happens because Linux, by default (at least on my case), overcommits memory:
This switch knows 3 different settings:
0: The Linux kernel is free to overcommit memory (this is the default), a heuristic algorithm is applied to figure out if enough memory is available.
1: The Linux kernel will always overcommit memory, and never check if enough memory is available. This increases the risk of out-of-memory situations, but also improves memory-intensive workloads.
2: The Linux kernel will not overcommit memory, and only allocate as much memory as defined in overcommit_ratio.
The default value on Debian is 0. This means that malloc won't fail, and the Kernel's OOM killer will get involved when the machine can't allocate new pages anywhere.
Further reading can be done at https://www.etalabs.net/overcommit.html