Steven mentioned that trace-cmd recently gained compression support. I suggest to remove zlib since there is no real benefit to use this compression algorithm. It might make sense to use zstd while dumping the per-CPU data files disks before the trace.dat is written. It probably makes sense to use zstd by default instead of storing the .dat file uncompressed. To put some numbers here: | time ./tracecmd/trace-cmd convert -i trace-none.dat -o trace-zlib.dat --compression zlib | real 9m43,699s | user 9m41,247s | sys 0m2,296s | | time ./tracecmd/trace-cmd convert -i trace-none.dat -o trace-zstd.dat --compression zstd | real 0m19,641s | user 0m17,768s | sys 0m1,868s | | time ./tracecmd/trace-cmd convert -i trace-none.dat -o trace-zstd-12.dat --compression zstd-12 | real 6m39,731s | user 6m37,735s | sys 0m1,908s The file sizes: Name Human Bytes (% of the original size) | trace-none.dat 11G 11240714240 | trace-zlib.dat 1,2G 1257455848 (~11.1%) | trace-zstd.dat 1,1G 1108957623 (~ 9.9%) | trace-zstd-12.dat 895M 937466831 (~ 8.3%) That is why wrote initially that it makes no sense to use zlib: zstd is approx 29 times faster while the compressed file is even slightly smaller. The higher zstd compression level (12 used, it goes higher) makes the even a little smaller the price appears too high. Sebastian
|