> Well, why it shouldn't?
Yeah, maybe it should. I don't know how exactly that's typically implemented, hence the question mark.
> Don't forget, while the RAM can be prepared (zeroed) fast, the on-disk swap can't be prepared that fast (compared to RAM ofc), and you already under some memory and disk constraints (that's how you got to be using the swap in the first place) so adding another workload for cleaning up the swap is... not a good thing.
I doubt any of that would typically involve the OS specifically zeroing anything apart from just marking the corresponding parts of the swap space as free. And that's probably in the in-memory data structures keeping track of pages in swap. No need to zero any of the page contents, just mark those areas of swap as unallocated.
An OS might want to keep the pages around for the sake of having thrm still around but unless otherwise shown, I kind of doubt there's a great cost to the deallocation itself.
> If you have a small swap then you would be pressured to evict the data from it more often.
I get that if indeed the OS keeps pages available (and in the books) in swap after swapping them back into RAM, having a larger swap can reduce writes in case those same pages end up getting swapped back out again before they've been modified. It may be that's how it works.
I'm not sure I follow the logic if that's not the case. I don't understand why the OS would "evict" pages from swap just because swap is getting full -- there's nowhere to evict them to except RAM.
If you've got thing A currently in swap and you're needing to "evict" it to make space in the swap for thing B, that means you're wanting to get rid of B in RAM. That means you're already needing more space in RAM for some third thing C, so why would you solve that by swapping pages of thing A from swap into RAM?
My understanding is that swapping pages back in would be initiated by needing those pages back in RAM, so that's not really a case of eviction.
Anyway, since it doesn't seem like either of us knows for an actual fact how it works in any particular OS, I doubt speculation will lead to anything better.
I believe what you've seen as a phenomenon, I'm just not sure the explanation of that phenomenon makes quite enough sense to me.
> See above, no such thing as TRIM on an encrypted storage device.
TRIM may have security implications for encrypted drives, e.g. in terms of plausible deniability for forensics, that's true, and I didn't think of that. Though I'm not sure if that's what you meant.