On Tue, Jul 11, 2017 at 09:51:16AM -0300, Arnaldo Carvalho de Melo wrote: > Right, we need to use the build-id and look it up in a database > populated somehow. > > perf right now, by default, collects the build-ids in a table, at the > end of the recording session, trying not to disrupt the monitored > workload by not processing anything, just reading from the buffers and > dumping to a file. > > It will also try to populate the build-id, trying first to make a > hardlink and copying it if it fails. > > If we can get the build-id at the time of the mmap(binary), as part of > the loading of binaries, that would be ideal, as we're touching the file > headers anyway and the build-id is a small enough cookie. > > But again, we should first try to do as far as we can with the > infrastructure we have in the kernel and tooling libraries, lots of > workloads will be serviced just fine with that.
Sorry, I was slow to pick up on what you're saying here. I agree that getting the build-id delivered in an event from the kernel would accelerate the process of determining whether you have or need to cache a binary in the build-id cache. Without such a modification, perf has to look at each binary to determine whether the build ids match. If we got the build-id in the event payload, then we only need to look to see if the build-id is cached. If it's not, then we can undertake the more complicated lookup path. That would be an improvement over what we can do today. -K
