5 ms·

Modern SSD are much faster at read than lz4, the fastest compression algorithm, at decompression and just 2-3 times slower in practice when writing than lz4 at

by _0w8t 5y ago

Modern SSD are much faster at read than lz4, the fastest compression algorithm, at decompression and just 2-3 times slower in practice when writing than lz4 at compression. And they do not tax CPU while doing that, which is important since heavy memory usage may come from CPU-intensive tasks. I did some benchmarks in my laptop and for heavy compilation tasks that may occasionally spike the memory usage over the amount of RAM memory compression was not beneficial compared with using SSD for swap. The picture changes if one needs encrypted storage and cannot use hardware encryption on SSD. The software encryption will tax CPU on roughly same scale as lz4 and lz4 is still faster overall for read/write combination.

etbe 5y ago
When I was using a Thinkpad X1 Carbon Gen6 with Linux it would hit a thermal limit and throttle the CPU speed if I read from NVMe at maximum speed for more than about 30 seconds. That was partly due to an issue with the way Linux and the BIOS interacted which gave a lower thermal limit than expected. But it really depends on what NVMe devices you use, I've seen cheap ones bottleneck at 30MB/s when doing continuous writes with no downtime. RAM is getting so cheap and easy to get that in recent years I only really use swap on laptops. Using a CPU core for compression isn't a big deal in a laptop because you usually have 4 cores and only 1 of them in use most of the time.
amarshall 5y ago
Huh? What numbers are you looking at? On my laptop (i7-1165G7, DDR4 3200 MHz) lz4 decompression is ~3000 MB/s, compression is ~485 MB/s (on my 3960X desktop it’s ~1.5x that) (numbers from lzbench). Zram by default uses one stream per CPU, so theoretical max is (I think) 8x those for the laptop and, well, a lot more for the Threadripper. Non-Optane SSDs only really have a potential advantage in sequential writing. Max throughput aside, Zram will generally have better latency (and thus likely IOPS as well), and better consistency since most SSDs get their max performance from DRAM caches. In the end, though, quibbling over synthetic numbers doesn’t matter much if you have benchmarked your actual use case. I don’t know what “not beneficial” means (the same? 10x worse?), but part of my original point was that
- amarshall 5y ago
  (somehow post got cut off, too late to edit) …part of my original point was that Zram will resolve the SSD endurance problems.
  - _0w8t 5y ago
    With modern big SSD endurance is no longer the issue. You would need to write at max speed for many month before hitting the limit. I had a laptop with 512GB SSD that I used heavily for 3 years for development work and then for 2 years as a backup machine with light usage. Its write counter reports only 7% of the max usage. So on a new laptop with 2TB SSD after benchmarking things I just disabled zram/zswap. But then again, it was critical to enable hardware encryption on SSD rather than using LUKS on Linux. The latter is so slow [1] that zram is really a must. [1] - https://www.reddit.com/r/Fedora/comments/rzvhyg/default_luks_encryption_settings_on_fedora_can_be/ https://www.reddit.com/r/Fedora/comments/rzvhyg/default_luks...
    - amarshall 5y ago
      Well it all depends on how much writing one does. OP estimates they have 1 year before they use too much of their drive’s endurance. Be aware that on-disk hardware encryption should generally not be trusted. It is not auditable or trivially verifiable. Some years back there were some revelations that some drive firmware encryption was woefully deficient. So much so that whereas Windows previously would treat on-disk encryption as sufficient, Microsoft stopped relying on it entirely.
      - _0w8t 5y ago
        I am aware of this. Plus there are constant power attacks when one disconnects the disk while the system is suspended when the key is unlocked on the disk. But this is a development machine and I figured out that surprisingly non-trivial overhead of LUKS encryption in Linux is not worth it. On the plus side wake up from hibernation is very fast and to mitigate the risk of the above I configured the laptop to hibernate shortly after suspend.

by _0w8t 5y ago

etbe 5y ago

When I was using a Thinkpad X1 Carbon Gen6 with Linux it would hit a thermal limit and throttle the CPU speed if I read from NVMe at maximum speed for more than about 30 seconds. That was partly due to an issue with the way Linux and the BIOS interacted which gave a lower thermal limit than expected. But it really depends on what NVMe devices you use, I've seen cheap ones bottleneck at 30MB/s when doing continuous writes with no downtime. RAM is getting so cheap and easy to get that in recent years I only really use swap on laptops. Using a CPU core for compression isn't a big deal in a laptop because you usually have 4 cores and only 1 of them in use most of the time.

amarshall 5y ago

Huh? What numbers are you looking at? On my laptop (i7-1165G7, DDR4 3200 MHz) lz4 decompression is ~3000 MB/s, compression is ~485 MB/s (on my 3960X desktop it’s ~1.5x that) (numbers from lzbench). Zram by default uses one stream per CPU, so theoretical max is (I think) 8x those for the laptop and, well, a lot more for the Threadripper. Non-Optane SSDs only really have a potential advantage in sequential writing. Max throughput aside, Zram will generally have better latency (and thus likely IOPS as well), and better consistency since most SSDs get their max performance from DRAM caches. In the end, though, quibbling over synthetic numbers doesn’t matter much if you have benchmarked your actual use case. I don’t know what “not beneficial” means (the same? 10x worse?), but part of my original point was that

amarshall 5y ago
(somehow post got cut off, too late to edit) …part of my original point was that Zram will resolve the SSD endurance problems.
- _0w8t 5y ago
  With modern big SSD endurance is no longer the issue. You would need to write at max speed for many month before hitting the limit. I had a laptop with 512GB SSD that I used heavily for 3 years for development work and then for 2 years as a backup machine with light usage. Its write counter reports only 7% of the max usage. So on a new laptop with 2TB SSD after benchmarking things I just disabled zram/zswap. But then again, it was critical to enable hardware encryption on SSD rather than using LUKS on Linux. The latter is so slow [1] that zram is really a must. [1] - https://www.reddit.com/r/Fedora/comments/rzvhyg/default_luks_encryption_settings_on_fedora_can_be/ https://www.reddit.com/r/Fedora/comments/rzvhyg/default_luks...
  - amarshall 5y ago
    Well it all depends on how much writing one does. OP estimates they have 1 year before they use too much of their drive’s endurance. Be aware that on-disk hardware encryption should generally not be trusted. It is not auditable or trivially verifiable. Some years back there were some revelations that some drive firmware encryption was woefully deficient. So much so that whereas Windows previously would treat on-disk encryption as sufficient, Microsoft stopped relying on it entirely.
    - _0w8t 5y ago
      I am aware of this. Plus there are constant power attacks when one disconnects the disk while the system is suspended when the key is unlocked on the disk. But this is a development machine and I figured out that surprisingly non-trivial overhead of LUKS encryption in Linux is not worth it. On the plus side wake up from hibernation is very fast and to mitigate the risk of the above I configured the laptop to hibernate shortly after suspend.