From: David Ahern <dsahern@gmail.com>
To: Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>
Cc: Namhyung Kim <namhyung@gmail.com>,
Namhyung Kim <namhyung@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Andi Kleen <andi@firstfloor.org>,
Stephane Eranian <eranian@google.com>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)
Date: Mon, 14 Dec 2015 07:55:32 -0700 [thread overview]
Message-ID: <566ED864.1040500@gmail.com> (raw)
In-Reply-To: <20151214093841.GB30347@gmail.com>
On 12/14/15 2:38 AM, Ingo Molnar wrote:
>
>> And in an unrelated note, I absolutely detest --buildid being the
>> default, it makes perf-record blow chunks.
Yes, a .debug directory that gets bloated fast and being a dot-directory
is off the primary radar. I forget about it and too often forget to add
the option to disable it.
>
> So I'd absolutely _love_ to split up the singular perf.data into a hierarchy of
> files in a .perf directory, with a structure like this (4-core system):
>
> .perf/cmdline
> .perf/features
> .perf/evlist
> .perf/ring_buffers/cpu0/raw.trace
> .perf/ring_buffers/cpu1/raw.trace
> .perf/ring_buffers/cpu2/raw.trace
> .perf/ring_buffers/cpu3/raw.trace
> ...
On a related note why a .perf directory?
>
> I.e. the current single file format of perf.data would be split up into individual
> files. Each CPU would get its own trace file output - any sorting and ordering
> would be done afterwards. 'perf record' itself would never by default have to do
> any of that, it's a pure recording session.
>
> 'perf archive' would still create a single file to make transport between machines
> easy.
>
> perf.data.old would be replaced by a .perf.old directory or so.
>
> Debugging would be easier too I think, as there's no complex perf data format
> anymore, it's all in individual (typically text, or binary dump) files in the
> .perf directory.
>
> This would solve all the scalability problems - and would make the format more
> extensible and generally more accessible as well.
>
> What do you think?
Big change to user experience.
I realize perf-archive has been around since I started using perf in
mid-2010, but I for one never use it. I suspect it is not widely used
(definitely not in the circles I have been involved and helped with
perf), so suddenly requiring it is a change in user experience.
The only 2 files on the system I pull off the box are kallsyms and
perf.data. Most of the systems where I use perf have limited symbols and
there is nothing in .debug I need to pull of the box.
next prev parent reply other threads:[~2015-12-14 14:55 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 7:53 [PATCHSET 00/16] perf top: Add multi-thread support (v1) Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 01/16] perf top: Delete half-processed hist entries when exit Namhyung Kim
2015-12-10 9:55 ` 平松雅巳 / HIRAMATU,MASAMI
2015-12-10 18:57 ` Arnaldo Carvalho de Melo
2015-12-14 8:15 ` [tip:perf/core] " tip-bot for Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 02/16] perf top: Fix and cleanup perf_top__record_precise_ip() Namhyung Kim
2015-12-10 19:04 ` Arnaldo Carvalho de Melo
2015-12-11 2:27 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 03/16] perf top: Factor out warnings about kernel addresses and symbols Namhyung Kim
2015-12-10 19:07 ` Arnaldo Carvalho de Melo
2015-12-14 1:44 ` Namhyung Kim
2015-12-14 2:02 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 04/16] perf top: Factor out warnings in perf_top__record_precise_ip() Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 05/16] perf top: Show warning messages in the display thread Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 06/16] perf top: Get rid of access to hists->lock in perf_top__record_precise_ip() Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 07/16] perf hists: Pass hists struct to hist_entry_iter struct Namhyung Kim
2015-12-13 23:15 ` Jiri Olsa
2015-12-14 1:45 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 08/16] perf tools: Export a couple of hist functions Namhyung Kim
2015-12-13 23:17 ` Jiri Olsa
2015-12-10 7:53 ` [PATCH/RFC 09/16] perf tools: Update hist entry's hists pointer Namhyung Kim
2015-12-13 23:23 ` Jiri Olsa
2015-12-13 23:28 ` Jiri Olsa
2015-12-14 1:51 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 10/16] perf hist: Add events_stats__add() and hists__add_stats() Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 11/16] perf top: Implement basic parallel processing Namhyung Kim
2015-12-14 9:23 ` Jiri Olsa
2015-12-14 9:35 ` Jiri Olsa
2015-12-15 2:08 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 12/16] perf tools: Reduce lock contention when processing events Namhyung Kim
2015-12-14 8:43 ` Jiri Olsa
2015-12-15 2:03 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 13/16] perf top: Protect the seen list using mutex Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 14/16] perf top: Separate struct perf_top_stats Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 15/16] perf top: Add --num-thread option Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 16/16] perf tools: Skip dso front cache for multi-threaded lookup Namhyung Kim
2015-12-10 8:01 ` [PATCHSET 00/16] perf top: Add multi-thread support (v1) Ingo Molnar
2015-12-10 8:49 ` Namhyung Kim
2015-12-11 8:11 ` Ingo Molnar
2015-12-11 15:01 ` David Ahern
2015-12-14 1:12 ` Namhyung Kim
2015-12-14 9:26 ` Peter Zijlstra
2015-12-14 9:38 ` Ingo Molnar
2015-12-14 14:55 ` David Ahern [this message]
2015-12-14 16:26 ` Arnaldo Carvalho de Melo
2015-12-14 16:41 ` Peter Zijlstra
2015-12-14 17:52 ` Arnaldo Carvalho de Melo
2015-12-14 16:38 ` Namhyung Kim
2015-12-14 16:56 ` Peter Zijlstra
2015-12-14 17:11 ` Namhyung Kim
2015-12-14 14:46 ` David Ahern
2015-12-14 17:06 ` Namhyung Kim
2015-12-14 17:54 ` Arnaldo Carvalho de Melo
2015-12-14 16:25 ` Namhyung Kim
2015-12-14 16:44 ` Peter Zijlstra
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=566ED864.1040500@gmail.com \
--to=dsahern@gmail.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@gmail.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;
as well as URLs for NNTP newsgroup(s).