On (22/09/05 22:06), Barry Song wrote: > > make sense! thanks! i assume you will have some benchmark data to compare > three cases, > 1. lzo with recompress zstd > 2. always use lzo > 3. always use zstd > > such as power consumption, cpu utilization, available memory, benefits to user > experiences especially to UI smoothness under memory pressure? So I didn't want to include any benchmarks, because this is entirely specific to device's data sets/patterns. In term of CPU usage, zstd decompression is really fast [1]; and the way plan to use is battery aware - e.g. when low on battery do not recompress at all, if AC is plugged in then recompress more aggressively, etc. In term of benchmarks... a copy paste from our internal tests. But *do note* that this is relative only to our specific data sets. Your millage may vary. ZSTD recomp algorithm (5.10 kernel, so the last column is the number of 'zram huge pages'): - Initial state of zram swap partition localhost ~ # cat /sys/block/zram0/mm_stat 8955662336 2180671776 2277711872 0 3179720704 798724 469474 118949 - Recompress HUGE objects only localhost ~ # echo huge > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8944390144 2106998658 2211835904 0 3179720704 798617 469474 66821 - Recompress IDLE pages that are >= 3000 bytes in size localhost ~ # echo 3000 > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8934166528 2085232505 2207690752 0 3179720704 798484 469474 66811 - Recompress the remaining IDLE pages that are >= 2000 bytes in size localhost ~ # echo 2000 > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8913981440 1946488434 2145157120 0 3179720704 798130 469474 66498 - Recompress the remaining IDLE pages that are >= 1000 bytes in size localhost ~ # echo 1000 > /sys/block/zram0/recompress localhost ~ # cat /sys/block/zram0/mm_stat 8905592832 1711533182 1984495616 0 3179720704 797162 469474 66222 [1] https://facebook.github.io/zstd/
