> No TRIM - no info about free blocks what could be safely and fully reused - more overall wear for SSD.
It's definitely possible to enable TRIM on an encrypted device, at least on LUKS. It requires specific support from the LUKS layer, though, and that requires software versions from the last decade or so and still isn't enabled by default:
https://askubuntu.com/questions/115823/trim-on-an-encrypted-...
https://askubuntu.com/questions/59519/do-you-recommend-luks-...
https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discar...
I originally hadn't remembered about the security implications or that it's not enabled by default, I just remembered it was possible, so "LUKS, therefore no TRIM" didn't seem to make sense. But yeah, it's not enabled by default.
> I'm not sure about the swap but memory nowadays is definitely zeroed before being allocated
Yeah, good point about switching between processes. Not sure it applies to swap, though, and I doubt that's zeroed, exactly because of what you said.
> Of course, but I do remember how the things worked back in the day (when the memory were constantly at the constraint because 16MBs isn't enough) and you definitely see the process with A and B swapping in and out, without any C, because you just used A and B, occasionally switching between them.
Yes, absolutely, that can happen. But if it's just between A and B without any third C, the entire need to move stuff between RAM and swap is initiated by the need to get A's pages into RAM in the first place (because A is trying to access them). Not by needing more space in swap for B's pages.
Having to write B's pages into swap is caused by memory pressure and the need to fit A's pages into constrained RAM rather than A's pages being "evicted" from swap being caused by a need to get B's pages into swap. You're already needing to get A out of the swap and into the RAM -- that's the initiating reason for the whole deal.
Once the OS switches between the processes again and some of B's pages need to be accessed in RAM, the OS may then need to write A's pages into swap again in order to make room for B's pages in RAM. But again it's due to memory pressure.
I don't see how swap size affects the amount of writes required in that scenario.
Unless, of course, the OS actually also keeps A's originally swapped copy of a page still around in swap after reading it back into RAM. In that case having a large enough swap to fully contain all the dirty pages of both A and B might reduce the amount of swap writes. If A, in the original scenario, only reads data from the accessed pages between the switches and doesn't modify them in the meantime, and the OS has kept its a copy of A's pages around in swap even after swapping the pages back into RAM, then of course when B runs again and its pages need to be read from swap back into RAM, the OS might be able to skip physically writing A's unmodified pages into swap again because their copies are already/still there.
If, that scenario, the swap is not large enough to contain both A and B's dirty pages, the OS had to drop the copies of A's pages from the swap to make room for B's, thus causing the need to physically write A's pages into swap again when switching back.
That's exactly what I was speculating about. Maybe that's what you meant by swap evictions?
I don't know if that's how OSes do it, though. It's possible but it would require some additional tracking of pages and their statuses.
If the OS does do that, then the size of the swap may potentially affect the amount of writes required to swap over time. Although it's only beneficial for pages that aren't modified in RAM between the swaps in and out.
If there is no such mechanism of keeping copies of pages around in swap even after reading them back into RAM, then I don't see how the size of the swap affects the amount of reads and writes.