linux-kernel - Re: [PATCH v2 0/4] perf: enable compression of record mode trace to save storage space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fd3989c7-e6e3-3805-72d1-a621d642e073@linux.intel.com>
Date:   Tue, 12 Feb 2019 17:06:03 +0300
From:   Alexey Budankov <alexey.budankov@...ux.intel.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/4] perf: enable compression of record mode trace to
 save storage space


On 12.02.2019 15:27, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 11, 2019 at 11:17:14PM +0300, Alexey Budankov escreveu:
>> This is the rebase to the tip of Arnaldo's perf/core repository.
>  
>> The patch set implements runtime trace compression for record mode and 
>> trace file decompression for report mode. Zstandard API [1] is used for 
>> compression/decompression of data that come from perf_events kernel 
>> data buffers.
>  
>> Realized -z,--compression_level=n option provides ~3-5x avg. trace file 
> 
> Realized? Perhaps "Using the -z/--compression_level=n options provides
> 3.5x average size reduction on..."

Yep, wording could be adjusted. Thanks!

> 
>> size reduction on variety of tested workloads what saves user storage 
>> space on larger server systems where trace file size can easily reach 
>> several tens or even hundreds of GiBs, especially when profiling with 
>> dwarf-based stacks and tracing of  context-switches.
>  
>> --mmap-flush option can be used to avoid compressing every single byte 
> 
> What is the default for --mmap-flush when -z is used? Does it vary with
> the compression level? Can we expect something that is reasonable or is
> using --mmap-flush always needed? If so can we do away with that by
> using some sensible default according to the -z level used?

Default value is 1 what is equal to the current perf record implementation. 
The option is independent from -z setting and doesn't vary with compression 
level. Default could be different if -z is specified.

> 
>> of data and increase compression ratio at the same time lowering tool 
>> runtime overhead.
>>
>>   $ tools/perf/perf record -z 1 -e cycles -- matrix.gcc
>>   $ tools/perf/perf record -z 1 --mmap-flush 1024 -e cycles -- matrix.gcc
>>   $ tools/perf/perf record -z 1 --mmap-flush 1024 --aio -e cycles -- matrix.gcc
> 
> Please avoid having these explanations just on the cover letter since it
> will not get recorded in the git history for the project, please add
> examples with output from real workloads, preferably providing real
> cases so that other people can readily replicate your results when
> having access to similar large machines.

Will do. Thanks!

>  
>> The compression functionality can be disabled from the command line 
>> using NO_LIBZSTD define and Zstandard sources can be overridden using 
>> value of LIBZSTD_DIR define:
>>
>>   $ make -C tools/perf NO_LIBZSTD=1 clean all
>>   $ make -C tools/perf LIBZSTD_DIR=/path/to/zstd-1.3.7 clean all
> 
> Showing the relevant output of the these commands before/after
> installing the libzstd library is useful as well. From what you use
> above is it fair to conclude that there are no readily made packages for
> this library and we need to get it from github and build it ourselves?

If your system has some version of the package preinstalled then the build 
system finds and uses it during the build. Auto detection feature status is 
reported just before compilation starts.

If you still prefer to compile with some newer version that is not 
preinstalled, and you don't want upgrading your system with newer version, 
you have capability to download, build and then refer the compilation to 
the newer just built library version using LIBZSTD_DIR.

> 
> On my notebook, a Fedora 29 system:
> 
> [root@...co ~]# dnf search zstd
> ========================================================== Name & Summary Matched: zstd ==========================================================
> zstd.x86_64 : Zstd compression library
> zstd.x86_64 : Zstd compression library
> libzstd.x86_64 : Zstd shared library
> libzstd.i686 : Zstd shared library
> libzstd.x86_64 : Zstd shared library
> libzstd-devel.i686 : Header files for Zstd library
> libzstd-devel.x86_64 : Header files for Zstd library
> ============================================================= Summary Matched: zstd ==============================================================
> fedora-repo-zdicts.noarch : Zstd dictionaries for Fedora repository metadata
> [root@...co ~]#
> [root@...co ~]# dnf install libzstd-devel
> <SNIP>
>  libzstd-devel                         x86_64                         1.3.8-1.fc29                          updates                          39 k
> <SNIP>
> 
> So, do I need some specific 1.3.7 version? Is that why you used that
> LIBZSTD_DIR in your example?

v1.3.7 is just an example. v1.3.8 can be also provided.

> 
> I'm trying these steps, but please consider following these suggestions
> in future posts,
> 
> And thanks for working on this!

Thanks for meaningful comments. Will do my best to follow it.

Thanks,
Alexey

> 
> - Arnaldo
>