On Tue, Jan 12, 2021 at 1:19 AM Jiri Olsa <jo...@redhat.com> wrote: > > On Mon, Jan 11, 2021 at 06:49:58PM -0800, Alexei Starovoitov wrote: > > On Mon, Jan 11, 2021 at 10:38:19PM +0100, Jiri Olsa wrote: > > > hi, > > > adding the support to have buildid stored in mmap2 event, > > > so we can bypass the final perf record hunt on build ids. > > > > > > This patchset allows perf to record build ID in mmap2 event, > > > and adds perf tooling to store/download binaries to .debug > > > cache based on these build IDs. > > > > > > Note that the build id retrieval code is stolen from bpf > > > code, where it's been used (together with file offsets) > > > to replace IPs in user space stack traces. It's now added > > > under lib directory. > > > > > > v6 changes: > > > - last 4 patches rebased Arnaldo's perf/core > > > > There were no issues with v5 as far as I can remember. > > This is just a resubmit to get it landed ? > > yes, exactly > > > Last time we couldn't quite figure out which tree to go through. > > I think the recommend path was to go via bpf-next. > > Is it still the case? > > bpf-next would be best for kernel changes, > perf: Add build id data in mmap2 event > bpf: Add size arg to build_id_parse function > bpf: Move stack_map_get_build_id into lib
Then please cc them to bpf@vger and add [PATCH bpf-next] otherwise it's all very confusing. > the 'perf buildid-cache' change needs to go through Arnaldo's tree, > because it depends on changes he already pulled in Also don't include the 4th patch in the series if it isn't meant for bpf-next.