From: Alexey Budankov <alexey.budankov@linux.intel.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/4] perf: enable compression of record mode trace to save storage space
Date: Tue, 12 Feb 2019 17:06:03 +0300 [thread overview]
Message-ID: <fd3989c7-e6e3-3805-72d1-a621d642e073@linux.intel.com> (raw)
In-Reply-To: <20190212122758.GH3269@kernel.org>
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@quaco ~]# 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@quaco ~]#
> [root@quaco ~]# 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
>
next prev parent reply other threads:[~2019-02-12 14:06 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 20:17 [PATCH v2 0/4] perf: enable compression of record mode trace to save storage space Alexey Budankov
2019-02-11 20:21 ` [PATCH v2 1/4] feature: realize libzstd check, LIBZSTD_DIR and NO_LIBZSTD defines Alexey Budankov
2019-02-11 20:22 ` [PATCH v2 2/4] perf record: implement -z=<level> and --mmap-flush=<thres> options Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 14:13 ` Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 14:13 ` Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 15:24 ` Alexey Budankov
2019-02-21 9:49 ` Jiri Olsa
2019-02-21 11:24 ` Alexey Budankov
2019-02-25 15:27 ` Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 14:15 ` Alexey Budankov
2019-02-21 9:47 ` Jiri Olsa
2019-02-21 11:23 ` Alexey Budankov
2019-02-25 15:26 ` Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 14:13 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 15:19 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 14:25 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 14:14 ` Alexey Budankov
2019-02-25 15:30 ` Alexey Budankov
2019-02-11 20:23 ` [PATCH v2 3/4] perf record: enable runtime trace compression Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 15:13 ` Alexey Budankov
2019-02-21 9:43 ` Jiri Olsa
2019-02-21 11:30 ` Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 14:53 ` Alexey Budankov
2019-02-21 9:43 ` Jiri Olsa
2019-02-21 11:18 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 15:09 ` Alexey Budankov
2019-02-25 15:27 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 15:11 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 15:03 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 15:06 ` Alexey Budankov
2019-02-11 20:25 ` [PATCH v2 4/4] perf report: support record trace file decompression Alexey Budankov
2019-02-12 13:08 ` Jiri Olsa
2019-02-20 15:19 ` Alexey Budankov
2019-02-25 15:28 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 14:48 ` Alexey Budankov
[not found] ` <0132ec08-e28b-4102-5053-8f8e21e7fd44@linux.intel.com>
2019-02-27 10:56 ` Alexey Budankov
2019-02-27 11:17 ` Jiri Olsa
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 14:46 ` Alexey Budankov
2019-02-12 13:09 ` Jiri Olsa
2019-02-20 14:44 ` Alexey Budankov
2019-02-12 12:27 ` [PATCH v2 0/4] perf: enable compression of record mode trace to save storage space Arnaldo Carvalho de Melo
2019-02-12 14:06 ` Alexey Budankov [this message]
[not found] <b834df0e-26b5-3f8c-7a43-18f675fb7434@linux.intel.com>
2019-01-29 10:45 ` Arnaldo Carvalho de Melo
2019-01-29 10:53 ` Arnaldo Carvalho de Melo
2019-01-29 11:39 ` Alexey Budankov
2019-01-29 12:13 ` Arnaldo Carvalho de Melo
2019-01-29 16:39 ` Alexey Budankov
2019-01-29 17:25 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2019-01-28 7:02 Alexey Budankov
2019-02-11 13:52 ` Jiri Olsa
2019-02-11 13:59 ` Alexey Budankov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd3989c7-e6e3-3805-72d1-a621d642e073@linux.intel.com \
--to=alexey.budankov@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox