On 2022-02-20 12:11:43 [-0500], Steven Rostedt wrote: > On Sun, 20 Feb 2022 00:01:50 +0100 > Sebastian Andrzej Siewior <sebastian@xxxxxxxxxxxxx> wrote: > > > 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. > > One benefit is to just have a test case for multiple versions. And who > knows, if it is an easy implementation, perhaps there's something that > needs it in a very limited embedded environment? Does it really hurt > keeping it, even though it may never be used? Especially in embedded environment I would prefer zstd over zlib because it performance. These days, if you can allow to compile trace-cmd you should be able to include zstd, too. One downside is probably that the zstd library is larger than libz. > > 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. > > I have a patch that does the compression by default. I'm holding off > pushing it until I finished my testing of the compressed versions. Awesome. I don't know how you make trace.dat in the end but I saw that there is one trace file per CPU first. Would it make sense to compress these before they are written to disk? > Thanks Sebastian for this update! You are welcome. > -- Steve Sebastian
|