From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Milian Wolff <mail@milianw.de>
Cc: linux-perf-users <linux-perf-users@vger.kernel.org>
Subject: Re: Size of perf data files
Date: Wed, 26 Nov 2014 13:06:17 -0300 [thread overview]
Message-ID: <20141126160617.GD30226@kernel.org> (raw)
In-Reply-To: <1601237.BEhNSa8l6d@milian-kdab2>
Em Wed, Nov 26, 2014 at 01:47:41PM +0100, Milian Wolff escreveu:
> I wonder whether there is a way to reduce the size of perf data files. Esp.
> when I collect call graph information via Dwarf on user space applications, I
> easily end up with multiple gigabytes of data in just a few seconds.
> I assume currently, perf is built for lowest possible overhead in mind. But
> could maybe a post-processor be added, which can be run after perf is finished
> collecting data, that aggregates common backtraces etc.? Essentially what I'd
> like to see would be something similar to:
> perf report --stdout | gzip > perf.report.gz
> perf report -g graph --no-children -i perf.report.gz
> Does anything like that exist yet? Or is it planned?
No, it doesn't, and yes, it would be something nice to have, i.e. one
that would process the file, find the common backtraces, and for that
probably we would end up using the existing 'report' logic and then
refer to those common backtraces by some index into a new perf.data file
section, perhaps we could use the features code for that...
But one thing you can do now to reduce the size of perf.data files with
dwarf callchains is to reduce the userspace chunk it takes, what is
exactly the 'perf record' command line you use?
The default is to get 8KB of userspace stack per sample, from
'perf record --help':
-g enables call-graph recording
--call-graph <mode[,dump_size]>
setup and enables call-graph (stack chain/backtrace) recording: fp dwarf
-v, --verbose be more verbose (show counter open errors, etc)
So, please try with something like:
perf record --call-graph dwarf,512
And see if it is enough for your workload and what kind of effect you
notice on the perf.data file size. Play with that dump_size, perhaps 4KB
would be needed if you have deep callchains, perhaps even less would do.
Something you can use to speed up the _report_ part is:
--max-stack <n> Set the maximum stack depth when parsing the
callchain, anything beyond the specified depth
will be ignored. Default: 127
But this won't reduce the perf.data file, obviously.
- Arnaldo
next prev parent reply other threads:[~2014-11-26 16:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 12:47 Size of perf data files Milian Wolff
2014-11-26 16:06 ` Arnaldo Carvalho de Melo [this message]
2014-11-26 18:11 ` Milian Wolff
2014-11-27 0:56 ` Namhyung Kim
2014-11-27 13:19 ` Arnaldo Carvalho de Melo
2014-11-28 6:18 ` Namhyung Kim
2014-11-26 20:48 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2015-01-06 3:21 Yale Zhang
2015-01-06 5:39 ` Andi Kleen
2015-01-06 21:02 ` Yale Zhang
2015-01-06 21:29 ` Andi Kleen
2015-01-09 2:06 ` Frank Ch. Eigler
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=20141126160617.GD30226@kernel.org \
--to=acme@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mail@milianw.de \
/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;
as well as URLs for NNTP newsgroup(s).