linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexey Budankov <alexey.budankov@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [RFC/PATCH 00/14] perf record: Add support to store data in directory
Date: Tue, 5 Feb 2019 14:37:27 +0100	[thread overview]
Message-ID: <20190205133727.GF4794@krava> (raw)
In-Reply-To: <CABPqkBQTpt0dhinJZc+mJ-JNvkU2M9DVx1G65ngWxZxk-eGBVA@mail.gmail.com>

On Mon, Feb 04, 2019 at 02:44:37PM -0800, Stephane Eranian wrote:
> Jiri,
> 
> While you're looking at the output format, I think it would be good
> time to simplify the code handling perf.data file.
> Today, perf record can emit in two formats: file mode or pipe mode.
> This adds complexity in the code and
> is error prone as the file mode path is tested more than the pipe mode
> path. We have run into multiple issues with
> the pipe mode in recent years. There is no real reason why we need to
> maintain two formats. If I recall, the pipe format
> was introduced because on pipes you cannot lseek to update the headers
> and therefore some of the information present as tables
> updated on the fly needed to be generated as pseudo records by the
> tool. I believe that the pipe format covers all the needs and could
> supersede the file mode format. That would simplify code in perf
> record and eliminate the risk of errors when new headers
> are introduced.

yep, I think we have almost all the features covered for pipe mode,
and we have all necessary events to describe events features

so with some effort we could switch off the superfluos file header
and use only events to describe events ;-) make sense, I'll check
on it

> 
> Related to your effort to make perf record multi-threaded, I was
> wondering how this would impact pipe mode.
> Could you explain?

there's no support for threaded pipe processing at the moment,
currently the data are stored in directory:

  $ ls -l perf.data
  total 344
  -rw-------. 1 jolsa jolsa 43864 Jan 20 22:26 data.0
  -rw-------. 1 jolsa jolsa 30464 Jan 20 22:26 data.1
  -rw-------. 1 jolsa jolsa 53816 Jan 20 22:26 data.2
  -rw-------. 1 jolsa jolsa 30368 Jan 20 22:26 data.3
  -rw-------. 1 jolsa jolsa 40088 Jan 20 22:26 data.4
  -rw-------. 1 jolsa jolsa 42592 Jan 20 22:26 data.5
  -rw-------. 1 jolsa jolsa 56136 Jan 20 22:26 data.6
  -rw-------. 1 jolsa jolsa 25992 Jan 20 22:26 data.7

  ^^^^ those are raw data files, contains only events with common header
        as stored by perf or kernel

  -rw-------. 1 jolsa jolsa  8832 Jan 20 22:26 header

  ^^^^ this one currently holds perf.data file header, describing events
       and features

if we switched to pipe mode by default we could omit the header file
and find a way to push the data streams through single file, like with
a new event describing the data stream.. we can have an option for that
so you could do something like:

  # perf record --threads --single-file -a ... | perf report -i -

however having single thread storing storing into single file without
any other processing is important on record side (for minimal overhead),
so I think we should keep creating the directory with data files also
for pipe mode to have minimal overhead

jirka

  reply	other threads:[~2019-02-05 13:37 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-03 15:30 [RFC/PATCH 00/14] perf record: Add support to store data in directory Jiri Olsa
2019-02-03 15:30 ` [PATCH 01/14] perf tools: Make rm_rf to remove single file Jiri Olsa
2019-02-05 11:33   ` Alexey Budankov
2019-02-05 13:38     ` Jiri Olsa
2019-02-03 15:30 ` [PATCH 02/14] perf session: Add process callback to reader object Jiri Olsa
2019-02-03 15:30 ` [PATCH 03/14] perf data: Move size to struct perf_data_file Jiri Olsa
2019-02-03 15:30 ` [PATCH 04/14] perf data: Add global path holder Jiri Olsa
2019-02-03 15:30 ` [PATCH 05/14] perf data: Make check_backup work over directories Jiri Olsa
2019-02-03 15:30 ` [PATCH 06/14] perf data: Add perf_data__(create_dir|free_dir) functions Jiri Olsa
2019-02-05 11:52   ` Alexey Budankov
2019-02-05 13:42     ` Jiri Olsa
2019-02-05 13:46   ` Arnaldo Carvalho de Melo
2019-02-05 13:53     ` Jiri Olsa
2019-02-03 15:30 ` [PATCH 07/14] perf data: Add perf_data__open_dir_data function Jiri Olsa
2019-02-03 15:30 ` [PATCH 08/14] perf data: Add directory support Jiri Olsa
2019-02-03 15:30 ` [PATCH 09/14] perf data: Don't store auxtrace index for directory data file Jiri Olsa
2019-02-03 15:30 ` [PATCH 10/14] perf data: Add perf_data__update_dir function Jiri Olsa
2019-02-03 15:30 ` [PATCH 11/14] perf data: Make perf_data__size to work over directory Jiri Olsa
2019-02-03 15:30 ` [PATCH 12/14] perf session: Add __perf_session__process_dir_events function Jiri Olsa
2019-02-03 15:30 ` [PATCH 13/14] perf session: Add path to reader object Jiri Olsa
2019-02-03 15:30 ` [PATCH 14/14] perf record: Add --dir option to store data in directory Jiri Olsa
2019-02-05 12:36   ` Alexey Budankov
2019-02-05 13:51     ` Jiri Olsa
2019-02-04 10:12 ` [RFC/PATCH 00/14] perf record: Add support " Alexey Budankov
2019-02-04 10:36   ` Jiri Olsa
2019-02-04 11:29     ` Alexey Budankov
2019-02-04 11:41       ` Jiri Olsa
2019-02-04 18:56         ` Stephane Eranian
2019-02-04 19:27           ` Arnaldo Carvalho de Melo
2019-02-04 19:56             ` Alexey Budankov
2019-02-04 20:05             ` Stephane Eranian
2019-02-04 20:28               ` Jiri Olsa
2019-02-04 22:44                 ` Stephane Eranian
2019-02-05 13:37                   ` Jiri Olsa [this message]
2019-02-11 10:19                     ` Jiri Olsa
2019-02-11 18:34                       ` Stephane Eranian
2019-02-11 18:53                         ` Jiri Olsa
2019-02-11 19:32                           ` Arnaldo Carvalho de Melo
2019-02-11 20:18                             ` Jiri Olsa
2019-02-11 20:43                               ` Stephane Eranian
2019-02-14 11:34                                 ` Jiri Olsa
2019-02-14 12:57                                   ` Arnaldo Carvalho de Melo
2019-02-14 13:26                                     ` Jiri Olsa
2019-02-14 13:59                                       ` Arnaldo Carvalho de Melo
2019-02-14 21:30                                         ` Stephane Eranian
     [not found]                                           ` <CA+JHD90ssKi3CJ7yfCFTkrS8xwUsZhvd0t7cSCy1MF7TJ2XLYw@mail.gmail.com>
2019-02-14 21:39                                             ` Stephane Eranian
2019-02-11 18:55                         ` Arnaldo Carvalho de Melo
2019-02-11 19:30                           ` Stephane Eranian
2019-02-11 20:30                             ` Song Liu

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=20190205133727.GF4794@krava \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=eranian@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.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).