[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190215182047.GL31177@kernel.org>
Date: Fri, 15 Feb 2019 15:20:47 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Song Liu <songliubraving@...com>
Cc: Jiri Olsa <jolsa@...nel.org>,
Stephane Eranian <eranian@...gle.com>,
Netdev <netdev@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>,
Kernel Team <Kernel-team@...com>,
"peterz@...radead.org" <peterz@...radead.org>,
"namhyung@...nel.org" <namhyung@...nel.org>
Subject: Re: [PATCH v2 perf,bpf 08/11] perf, bpf: save btf information as
headers to perf.data
Em Fri, Feb 15, 2019 at 05:47:58PM +0000, Song Liu escreveu:
>
>
> > On Feb 15, 2019, at 9:40 AM, Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> >
> > Em Fri, Feb 15, 2019 at 05:25:01PM +0000, Song Liu escreveu:
> >>> On Feb 15, 2019, at 6:26 AM, Arnaldo Carvalho de Melo <acme@...hat.com> wrote:
> >>> Em Thu, Feb 14, 2019 at 04:00:09PM -0800, Song Liu escreveu:
> >>>> This patch enables perf-record to save btf information as headers to
> >>>> perf.data A new header type HEADER_BTF is introduced for this data.
> >
> >>> Wouldn't it be better for this HEADER_BTF to be introduced
> >>> already as an user space event, Song, see:
> >
> >>> tools/perf/util/event.h
> >
> >>> and:
> >
> >>> tools/perf/util/event.c
> >
> >>> perf_event__synthesize_cpu_map()
> >
> >> BTF would be short living for short living BPF programs. I guess
> >> saving them as header is easier than merging them with samples.
> >
> >> What's the benefit of saving them as user space events?
> >
> > When we work with pipe mode, i.e.:
> >
> > perf record -o - | perf report -i -
> >
> > and other combinations (with 'perf script', 'perf inject', etc), we need
> > a way to pass the headers to the other side, and the way was via user
> > space events.
> >
> > This is something Stephane and Jiri have been discussing recently,
> > probably they have more justifications, Stephane, Jiri?
> >
> > - Arnaldo
>
> I see. In this case, we will need some synchronization between main
> thread and the polling thread, as they are both writing to the same
> pipe.
So, the whole context is that we need to have 'perf record' to start a
thread per CPU and then read the already per-cpu mmap buffers in the
matching thread, with the right affinity, numa settings to have the
record phase not cause contention, etc, so it ends up dumping one stream
per CPU in a separate file in a 'perf.data' directory instead of a
perf.data file.
Jiri is working on that, so, if you dump one more stream into that
directory, it would, at post processing time, be ordered together with
the other stream, the per-cpu ones.
- Arnaldo
Powered by blists - more mailing lists