From: Jiri Olsa <jolsa@redhat.com>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
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 v1 0/4] perf: enable compression of record mode trace to save storage space
Date: Mon, 14 Jan 2019 12:03:25 +0100 [thread overview]
Message-ID: <20190114110325.GB22336@krava> (raw)
In-Reply-To: <b1df6115-e03c-47f4-bdb8-29f1980763f0@linux.intel.com>
On Mon, Jan 14, 2019 at 11:43:31AM +0300, Alexey Budankov wrote:
> Hi,
> On 09.01.2019 20:28, Jiri Olsa wrote:
> > On Mon, Dec 24, 2018 at 04:21:33PM +0300, Alexey Budankov wrote:
> >>
> >> The patch set implements runtime record trace compression accompanied by
> >> trace file decompression implemented in the tool report mode. Zstandard
> >> library 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
> >> size reduction on the tested workloads what significantly saves user's
> >> storage space on larger server systems where trace file size can easily
> >> reach several tens or even hundreds of GiBs, especially when profiling
> >> with stacks for later dwarf unwinding, context-switches tracing and etc.
> >>
> >> The option is effective jointly with asynchronous trace writing because
> >> compression requires auxiliary memory buffers to operate on and memory
> >> buffers for asynchronous trace writing serve that purpose.
> >
> > I dont like that it's onlt for aio only, I can't really see why it's
>
> For serial streaming, on CPU bound codes, under full system utilization it
> can induce more runtime overhead and increase data loss because amount of
> code on performance critical path grows, of course size of written data
> reduces but still. Feeding kernel buffer content by user space code to a
> syscall is extended with intermediate copying to user space memory with
> doing some math on it in the middle.
>
> > a problem for normal data.. can't we just have one layer before and
> > stream the data to the compress function instead of the file (or aio
> > buffers).. and that compress functions would spit out 64K size COMPRESSED
> > events, which would go to file (or aio buffers)
>
> It is already almost like that. Compression could be bridged using AIO
> buffers but then still streamed to file serially using record__pushfn()
> and that would make some sense for moderate profiling cases on systems
> without AIO support and trace streaming based on it.
>
> >
> > the report side would process them (decompress) on the session layer
> > before the tool callbacks are called
>
> It is already pretty similar to that.
hum, AFAICS you do that in report code not in on the session layer
jirka
next prev parent reply other threads:[~2019-01-14 11:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-24 13:21 [PATCH v1 0/4] perf: enable compression of record mode trace to save storage space Alexey Budankov
2018-12-24 13:35 ` [PATCH v1 1/4] feature: build libzstd feature check, LIBZSTD_DIR and NO_LIBZSTD defines Alexey Budankov
2018-12-24 13:45 ` [PATCH v1 2/4] perf record: introduce z, mmap-flush options and PERF_RECORD_COMPRESSED record Alexey Budankov
2019-01-09 16:58 ` Jiri Olsa
2019-01-14 8:46 ` Alexey Budankov
2018-12-24 13:46 ` [PATCH v1 3/4] perf record: enable runtime trace compression Alexey Budankov
2018-12-24 14:00 ` [PATCH v1 4/4] perf report: support record trace file decompression Alexey Budankov
2019-01-09 17:28 ` [PATCH v1 0/4] perf: enable compression of record mode trace to save storage space Jiri Olsa
2019-01-14 8:43 ` Alexey Budankov
2019-01-14 11:03 ` Jiri Olsa [this message]
2019-01-14 11:26 ` 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=20190114110325.GB22336@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.budankov@linux.intel.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