It sounds ominous, but I think I have thought it through. My reasons for not having a swap partition are:
I’m running on a simple SSD (eMMC, in fact) with limited space and write endurance. (I believe that I can use the space better.)
This is for an embedded-ish system, and it shoulnd’t run arbitrary software. If it runs out of memory, I’d rather know it straight away (OOM killing something), rather than the entire system becoming sluggish with swap thrashing.
It looks like the swap was never used. (On a system that had been running for a couple of months, I did dd if=/dev/mmsblk1p2 | hexdump -C and it contained only 0x00 (except for a header).).
Is that reasoning alright? Or have I missed something?
Would it make sense to set up something like zswap instead?
If after a couple of month in a real use case scenario, the system never used the swap, I would think it should be fine.
The performance improvement of having a swap comes with the ratio that determines when to put “cold memory” pages of a process in swap and free memory for, for example, page caches (file system cache). Imagine there is a process that it is rather dormant, and another process is launched to do something, which calls some decent amount of file system ops. The OS sees that there is not much free memory, and then it can decide to put the dormant process to the swap, and free the memory to accommodate more page cache for the new process that started, so the new process can perform even better and faster when operating on the file system. That ratio is the swappiness. A higher swappiness makes the kernel prefer to free memory for page caches. A low one makes the kernel prefer to keep the “cold” pages of processes in memory, at the expense of reclaiming more page caches. It depends on your use case, really.
