linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).