Messages in this thread | | | From | Song Liu <> | Subject | Re: [PATCH v2 perf,bpf 08/11] perf, bpf: save btf information as headers to perf.data | Date | Fri, 15 Feb 2019 18:59:14 +0000 |
| |
> On Feb 15, 2019, at 10:20 AM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > 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@kernel.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@redhat.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
I see. This solution looks great.
For this set, how about I keep this part as-is (at least for v3)? In this case, it will goes to the header file after Jiri's change. Once Jiri's work is done, I will move them into per-cpu files.
Thanks, Song
| |