Swap space is not just for overcommitting memory (in fact, I suspect nowadays it rarely ever is), but also for improving performance by maximizing efficient usage of RAM.
With 48GB, you're probably fine, but run a few VMs or large programs, and you're backing your kernel into a corner in terms of making RAM available for efficient caching.
I have memories from like 20 years ago that even when I had plenty of RAM, and plenty of it was free, I would get random OOM killer events relatively regularly. Adding just a tiny bit of swap made that stop happening.
I'm like 90% sure at this point it's just a stupid superstition I carry. But I'm not gonna stop doing it even though it is stupid.
MiB Swap: 32768.0 total, 32768.0 free, 0.0 used.
I could safely get away with 4GB of swap, and see no difference.Instead of achieving responsiveness by disabling swap entirely (which is silly, because everyone has some very cold pages that don't deserve to be stuck in memory), people should mlockall essential processes, adjust the kernel's VM swap propensity, and so on.
Also, I wish we'd just do away with the separation between the anonymous-memory and file-backed memory subsystems entirely. The only special about MAP_ANONYMOUS should be that its backing file is the swap file.
Having no swap limits how much you can overburden your computer, but you also hit problems earlier. Here's some example numbers for 64GB of memory: With swap you can go up to 62GB of active program data (85GB allocated and used) before you have performance issues. Without swap you can go up to 45GB of active program data (63GB allocated and used) before you hit a brick wall of either thrashing or killing processes. The no-swap version is better at maintaining snappiness within its happy range, but it's a tradeoff.
Also, that separate policy shouldn't even exist. For LRU/active-list/inactive-list purposes, why does it matter whether a page is anonymous or file-backed? If you need it, you need it, and if you don't, you don't. No reason for anonymous and file-backed memory to be separate sub-sub-systems under vm.