Yes, one example where overcommit can be better than swap is Redis. When redis is persisting its state to disk, it temporarily needs 2x the memory because it f

Yes, one example where overcommit can be better than swap is Redis. When redis is persisting its state to disk, it temporarily needs 2x the memory because it forks a child that does this in the background. Since fork uses copy-on-write, only the difference between child/parent is actually consumed as extra memory. The rest is "de-duplicated" in a sense. The choice is then to 1) enable swap, possibly killing performance 2) enable overcommit, possibly killing the redis process It is sometimes preferable for a service to fail hard and fast than get bogged down with swap. I believe this is the idea behind the "no swap" policy, at least on Linux. Redis is a good example here because any amount of swapping will kill performance since literally all of its allocated memory is consistently accessed for the purposes of doing a dump. And Linux will always try to swap things out, even with vm.swappiness=1.