Re: [RFC/PATCH 00/14] perf record: Add support to store data in directory

[Jiri Olsa]

On Thu, Feb 14, 2019 at 09:57:59AM -0300, Arnaldo Carvalho de Melo wrote:
> 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@xxxxxxxxxx> 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.

ok.. it might little change the expected behavour in that
you will not have .debug cache populated until you run
perf archive.. some profile data might stop report after
you reinstall the binary..

on the other hande '.debug' cache would stop growing
uncontrolably.. so I think I'd be ok with this

jirka