3 ms·

> And with auto-leveling all you really need (if you care that much) is to.. increase the swap size, so there would be less evictions from the swap => less writ

by Delk 3y ago

> And with auto-leveling all you really need (if you care that much) is to.. increase the swap size, so there would be less evictions from the swap => less writes. How does that work out? To where would data be evicted from swap? Increased swap size might of course help with wear leveling if that means there's just more unallocated space on the device. > But anyway, even modern TLC drives would be fine for a decade if this is just a machine used for a couple of hours everyday. You need like a constant 3MB/s 24/7 to even be close for their rated TBW. Mine hasn't even been just a couple of hours every day. Sure, during a regular work week it might not be used a whole lot, but I've used it for entire days e.g. when I was doing my master's full-time. Again, not a whole lot of memory intensive work, but not intentionally conservative for a general-purpose laptop either. Running just about any kind of a game often means some of the memory of the umpteen browser processes get swapped out.

justsomehnguy 3y ago
> To where would data be evicted from swap? This is actually an interesting question, but this is quite obvious if you know how it works. Consider this scenario: Some app loads data (it goes to RAM), sometime later this data is moved to the swap. Now the app is trying to access it, so there are two ways: there is no free RAM (eg other apps locked the physical memory), so the access is going through the swap there are free memory blocks so the OS copies the accessed data to the RAM, app is working fast... but till the data is modified, there is no need to mark the data in the swap as a stale, so until it happens the OS can wipe the RAM and redirect the app to the swap. Now consider another app is pressured to moved to the swap at the same time: If there is not enough swap space, then the data of the first app, which has [a valid, synced] data both in the RAM and the swap is just left with with the data in the RAM and the swap space is freed to accomodate the data of the second app. If turntables (sic) the process would repeat, just with the both apps trading places. But if there is enough swap space available, the second app data is just written to the spare swap blocks, and both apps' data could be read from the swap at any time. Quite simple. > Increased swap size might of course help with wear leveling if that means there's just more unallocated space on the device. This is a thing too, ofc, but the main point is having less 'overwrites' per usable space. > Mine hasn't even been just a couple of hours every day. It's even 'worse' than that. I've seen a server with 850/860 Evos and LUKS (so the worst case: cheap drives and all writes are new), even after the 3 years they were only 50% of 'ssd health'. TLC is the worst thing happened to SSDs as a technology, but people are forgetting what 3MB/s * 3600 * 24 is whooping 259GB a day, and you need to write ~259GB a day for 3 years to totally deplete the [official] write endurance (YssdMV). Wanna hear about 5 WD10JUCT?
- Delk 3y ago
  Right. So, when swapping pages back into RAM, a typical OS will not actually remove the pages from swap despite them now being in RAM as well? So if the memory needs to be freed again for another purpose before the pages in memory have been modified in the interim, the OS can just drop the pages from RAM without having to write them into swap again? And thus thrashing causes more swap writes when there's limited swap space. That's the only scenario I can think of. I didn't think about pages not being removed from swap when swapping in. > I've seen a server with 850/860 Evos Well, that's desktop-grade hardware in a server. Might work, but if it doesn't, you get what you asked for. > and LUKS (so the worst case: cheap drives and all writes are new) How does LUKS affect that? > people are forgetting what 3MB/s * 3600 * 24 is whooping 259GB a day, and you need to write ~259GB a day for 3 years to totally deplete the [official] write endurance (YssdMV). Right, this was my point. That's not an impossible amount of writes but it is a lot more than almost anybody does on a laptop/desktop.
  - justsomehnguy 3y ago
    > OS will not actually remove the pages from swap despite them now being in RAM as well Now the hard part: I don't have an idea, because I'm no that versed in OS VMM, but it does make sense even if it is 1993. But this is the basics and I doubt it works some other way. I would be happy if someone more familiar would chime in (and the reason why or not), but in my experience this is what happening. > Well, that's desktop-grade hardware in a server. Might work, but if it doesn't, you get what you asked for. Extremely often and works not just 'quite well', but well enough. Similiar servers (literally, just without LUKS) were fine, with > 90% of 'SSD health' > How does LUKS affect that Every write is different, because the bytes on the storage are already encrypted. Ie you write the same bytes to the same blovk pn the FS, but the underlaying, encrypted, bytes are not the same => new write. > Right, this was my point. Yep.
    - Delk 3y ago
      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. > Every write is different, because the bytes on the storage are already encrypted. Ie you write the same bytes to the same blovk pn the FS, but the underlaying, encrypted, bytes are not the same => new write. How are they not the same as the previous encrypted version of the same bytes if the encryption key stays the same? Are you sure TRIM/discard just wasn't enabled on the LUKS?

by Delk 3y ago

justsomehnguy 3y ago

> To where would data be evicted from swap? This is actually an interesting question, but this is quite obvious if you know how it works. Consider this scenario: Some app loads data (it goes to RAM), sometime later this data is moved to the swap. Now the app is trying to access it, so there are two ways: there is no free RAM (eg other apps locked the physical memory), so the access is going through the swap there are free memory blocks so the OS copies the accessed data to the RAM, app is working fast... but till the data is modified, there is no need to mark the data in the swap as a stale, so until it happens the OS can wipe the RAM and redirect the app to the swap. Now consider another app is pressured to moved to the swap at the same time: If there is not enough swap space, then the data of the first app, which has [a valid, synced] data both in the RAM and the swap is just left with with the data in the RAM and the swap space is freed to accomodate the data of the second app. If turntables (sic) the process would repeat, just with the both apps trading places. But if there is enough swap space available, the second app data is just written to the spare swap blocks, and both apps' data could be read from the swap at any time. Quite simple. > Increased swap size might of course help with wear leveling if that means there's just more unallocated space on the device. This is a thing too, ofc, but the main point is having less 'overwrites' per usable space. > Mine hasn't even been just a couple of hours every day. It's even 'worse' than that. I've seen a server with 850/860 Evos and LUKS (so the worst case: cheap drives and all writes are new), even after the 3 years they were only 50% of 'ssd health'. TLC is the worst thing happened to SSDs as a technology, but people are forgetting what 3MB/s * 3600 * 24 is whooping 259GB a day, and you need to write ~259GB a day for 3 years to totally deplete the [official] write endurance (YssdMV). Wanna hear about 5 WD10JUCT?

Delk 3y ago
Right. So, when swapping pages back into RAM, a typical OS will not actually remove the pages from swap despite them now being in RAM as well? So if the memory needs to be freed again for another purpose before the pages in memory have been modified in the interim, the OS can just drop the pages from RAM without having to write them into swap again? And thus thrashing causes more swap writes when there's limited swap space. That's the only scenario I can think of. I didn't think about pages not being removed from swap when swapping in. > I've seen a server with 850/860 Evos Well, that's desktop-grade hardware in a server. Might work, but if it doesn't, you get what you asked for. > and LUKS (so the worst case: cheap drives and all writes are new) How does LUKS affect that? > people are forgetting what 3MB/s * 3600 * 24 is whooping 259GB a day, and you need to write ~259GB a day for 3 years to totally deplete the [official] write endurance (YssdMV). Right, this was my point. That's not an impossible amount of writes but it is a lot more than almost anybody does on a laptop/desktop.
- justsomehnguy 3y ago
  > OS will not actually remove the pages from swap despite them now being in RAM as well Now the hard part: I don't have an idea, because I'm no that versed in OS VMM, but it does make sense even if it is 1993. But this is the basics and I doubt it works some other way. I would be happy if someone more familiar would chime in (and the reason why or not), but in my experience this is what happening. > Well, that's desktop-grade hardware in a server. Might work, but if it doesn't, you get what you asked for. Extremely often and works not just 'quite well', but well enough. Similiar servers (literally, just without LUKS) were fine, with > 90% of 'SSD health' > How does LUKS affect that Every write is different, because the bytes on the storage are already encrypted. Ie you write the same bytes to the same blovk pn the FS, but the underlaying, encrypted, bytes are not the same => new write. > Right, this was my point. Yep.
  - Delk 3y ago
    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. > Every write is different, because the bytes on the storage are already encrypted. Ie you write the same bytes to the same blovk pn the FS, but the underlaying, encrypted, bytes are not the same => new write. How are they not the same as the previous encrypted version of the same bytes if the encryption key stays the same? Are you sure TRIM/discard just wasn't enabled on the LUKS?