4 ms·

If the OS didn't keep the pages around in swap after they were swapped back into RAM, I don't see how having more space in swap could reduce writes to it. > Ev

• justsomehnguy 3y ago
  > If the OS didn't keep the pages around in swap after they were swapped back into RAM Well, why it shouldn't? 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. If you only would do 'zero on allocate' then sooner or later you would be in a position where you would need to stall the whole system until enough pages in the swap are available. And nor the users nor the programs like that. > I don't see how having more space in swap could reduce writes to it. Swap is just 'slow memory' part of your overall virtual memory allocation of the whole OS. If you have a small swap then you would be pressured to evict the data from it more often. If you have a big swap then less pressure => less evictions => less overwriting the same LBAs assigned to the swap file/partition => less writes overall. > How are they not the same as the previous encrypted version of the same bytes if the encryption key stays the same? Even if you write 00000000 to the filesystem block (a typical situation would be deleting a file and on the flash/SMR drives you would just call TRIM on those bytes^W LBAs) it's not 00000000 down there, it's some ciphertext. > Are you sure TRIM/discard just wasn't enabled on the LUKS? See above, no such thing as TRIM on an encrypted storage device.
  • Delk 3y ago
    > 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.
    • justsomehnguy 3y ago
      > Though I'm not sure if that's what you meant. No TRIM - no info about free blocks what could be safely and fully reused - more overall wear for SSD. > 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 I'm not sure about the swap but memory nowadays is definitely zeroed before being allocated[0], not only it's more safe on security side of this, it's way more stable. Imagine a buffer overrun bug which wouldn't manifest itself if the PC was freshly booted (ie all memory is zeroes) but after a couple of hours it writes 0x10 blocks but reads 0x100 and executes them? With all the garbage what was left there by previous processes... Obviously[1], zeroing the swap is expensive and questionable practice, if you are swapping from the RAM then you overwrite the corresponding parts anyway... Guess I was over(under?)-thinking the process. > 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. 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. [0] https://stackoverflow.com/questions/18385556/does-windows-clear-memory-pages#18386097 https://stackoverflow.com/questions/18385556/does-windows-cl... [1] well, now, after a fresh look and at the desktop
      • Delk 3y ago
        > 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-ssd https://askubuntu.com/questions/115823/trim-on-an-encrypted-... https://askubuntu.com/questions/59519/do-you-recommend-luks-encryption-on-a-ssd-trim-support https://askubuntu.com/questions/59519/do-you-recommend-luks-... https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD) 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.