When the Mem.MemMinFreePct value is set to 0, ESXi will calculate the MemMinFreePct threshold using the following formula and adding the results:
| Threshold | Memory range | Result (host with 256GB) | Result (host with 512GB) |
| 6% | 0-4GB | 245.76MB | 245.76MB |
| 4% | 4-12GB | 327.68MB | 327.68MB |
| 2% | 12-28GB | 327.68MB | 327.68MB |
| 1% | Remaining memory | 2334.72MB | 4956.16MB |
| Total High Threshold | 3235.84MB (3.16GB) | 5857.28MB (5.72GB) |
is then used to activate the memory reclamation method for the Soft, Hard, and Low thresholds:
| Free memory state | Threshold | Reclamation method | Threshold (host with 256GB) | Threshold (host with 512GB) |
| Soft | 64% | Balloon | 2070.93MB (2.02GB) | 3748.65MB (3.66GB) |
| Hard | 32% | Balloon, compress | 1035.46MB (1.01GB) | 1874.32MB (1.83GB) |
| Low | 16% | Balloon, compress, swap | 517.73MB (0.50GB) | 937.16MB (0.91GB) |
In a nutshell, the MemMinFreePct parameter defines the minimal amount of free memory desired in the system. Falling below this level will cause the system to reclaim memory through ballooning or swapping.
So, the amount of memory VMkernel keeps free is controlled by the value of MemMinFreePct, which is now determined using a sliding scale. This means that when free memory is greater than or equal to the derived value, the host is not under memory pressure.
Even if a host is under memory pressure, it just means that less free pRAM is available than is preferred. It does not mean that a performance problem is currently present. Because VMs often have extra vRAM and because the hypervisor doesn't know how much vRAM is considered free by the guest operating system, pRAM is often allocated to back vRAM, which holds junk data and could be freed for use elsewhere without any negative performance impact.