From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>,
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: Thu, 14 Feb 2019 09:57:59 -0300 [thread overview]
Message-ID: <20190214125759.GS3269@kernel.org> (raw)
In-Reply-To: <20190214113450.GC26714@krava>
Em Thu, Feb 14, 2019 at 12:34:50PM +0100, Jiri Olsa escreveu:
> On Mon, Feb 11, 2019 at 12:43:22PM -0800, Stephane Eranian wrote:
> > On Mon, Feb 11, 2019 at 12:18 PM Jiri Olsa <jolsa@redhat.com> wrote:
> > > I thought having new MMAP3 event version with buildid field in it
> > > if available and/or enabled by bit in perf_event_attr
> > I think MMAP3 is a cleaner approach, though it adds yet another MMAP event.
> actually I realized this might not help at the end at all
> what we do now is that we scan the data (after it's recorded)
We wouldn't have to do that scan of the data at the end if we have the
build-id in the MMAP3 records.
> to get the list of binaries that got touched during the profile
> and store those in .debug cache based on the build ids
> we can't just store ALL of the binaries that the session comes
> across via mmap events
We don't have to, we never did that at 'perf record' time, this is
something for 'perf archive' to do, see below.
> I can see the build id in mmap helping to resolve the race
> issue when some binary change during the profile session and
> we have no idea and report on wrong one.. but I dont see
> people complaining about this at all
But with the build id in the MMAPs we wouldn't need to scan anything at
'perf record' time, just at 'perf archive' time, where we would scan
everything, and as soon as we find a hit, we add that DSO to the list of
things we need to put in the tarball.
- Arnaldo
next prev parent reply other threads:[~2019-02-14 12:58 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
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 [this message]
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=20190214125759.GS3269@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--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=jolsa@redhat.com \
--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).