On Sat, Aug 1, 2020 at 6:43 AM Artem Tim <ego.cordatus@xxxxxxxxx> wrote: > > @Chris, thanks, i did some tests and now we have some numbers. tl;rd the results is pretty satisfying me, even if there no speedup in my case, but there is a lot disk space could be saved and reduce writes. Probably not worth file a bug, but a little bit weird that with zstd:1 still a little bit slower on HDD and on SSD speed equal. Your results look consistently faster with compression, whether HDD or SSD. > ## Results (HDD) > > ### Compression: lzo > Took: 6m53s > ### Compression: zstd:1 > Took: 7m5s > ### Compression: none > Took: 7m18s > > ## Results (SSD) > > ### Compression: lzo > Took: 2m26s > > ### Compression: zstd:1 > Took: 2m26s > ### Compression: none > Took: 2m24s There are quite a lot of complexities when benchmarking compression with workloads. The compression CPU hit is bigger than decompression, and also the decompression cpu and performance is fairly invariant to the level used for compression. This generally means we're more likely to be concerned about negatively impacting max write performance. Some compiles, while they involve lots of writes, don't ever reach the max write rate capability of storage, but are very CPU bound processes. Is it the small amount of CPU, or context switches, that impacts the writes? I don't know. Whereas for ~/.cache - for example Firefox and Chrome, these are tons of small file writes happening all the time and the less to flush the better, and also the less to read later on the better. This might be a good candidate for compression, as well as /var /etc /usr. None of those experience heavy writes that are also time sensitive, about the heaviest is a system upgrade and since those take long enough most folks walk away from them anyway, it might not be a big deal if took slightly longer, although so far I haven't seen that happen. I think the most common case where compression can slow things down is heavy writes to very fast media like NVMe. The NVMe writes are simply faster. And yet, I run compress=zstd:1 on NVMe all day long for all workloads and at least anecdotally it seems no different than without compression or using plain ext4 - and for sure it's all more responsive than when I reboot this same hardware and use Windows 10. I'll summarize 2 of the 4 ways to do compression by default on Fedora, that I've thought of so far. https://bugzilla.redhat.com/show_bug.cgi?id=1851276 a. Anaconda %pre-install script to (1) create /etc /var /usr (2) set a compression zstd XATTR on them. Everything inherits this as the installation happens. b. Anaconda kickstart `--fsoptions compress=zstd:1` will cause that mount option to be used for the installation and add it to fstab. Use %post install script to set a NOCOMPRESS flag on /home. These are not identical, but approximately equivalent. Perhaps the most significant difference is the visibility of the compression option in fstab. This might be a good thing or bad thing, depending on whether the user thinks this compression is happening system wide or not. The other difference is that with the (b) option, any new subvolumes created inside /home do *not* inherit NOCOMPRESS. Should it? Well that's a different conversation, I've gone back and forth on it myself and can argue it both ways, but generally I think maybe it shouldn't inherit because ostensibly a subvolume is a dedicated/independent files tree and should instead inherit file system defaults (and mount options modifying them) rather than XATTR inheritance rules. All of this is already implemented in the installer, so no churn there. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
