On Fri, 12 Sep 2014 11:11:16 -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Sep 12, 2014 at 03:14:51PM +0900, Namhyung Kim escreveu: >> On Fri, 5 Sep 2014 12:44:02 -0300, Arnaldo Carvalho de Melo wrote: >> > It seems we need a way to state that an entry in the build-id table is >> > for the kernel, without looking at its file name. > >> Maybe we can add a new build_id2_event (like mmap2) that has a new field >> to record that info. > > Humm, take a look at machine__write_buildid_table() -> write_buildid(), > we already seem to set build_id_event.header.misc suitably, no? AFAIK the PERF_RECORD_MISC_KERNEL is set for both of kernel image and modules so we cannot distinguish a kernel from others (without checking names). > >> > That or to put the build-id into the synthesized kernel mmap >> > event. Which is better, because: > >> > That leads to another problem that needs to get solved eventually: We >> > need to have the build-id into PERF_RECORD_MMAP, because we're now using >> > just the mmap filename as the key, not the contents, and for long >> > running sessions, DSOs can get updated, etc. > >> But it'd require a realtime processing of events at record time. > > Been there, done that, backtracked, yes, we can't do that at 'record > time', else we would be adding way too much noise to the recording > phase. > > The idea is for the _kernel_ to do that, would take sizeof(buildid) > (about 20 bytes) on the per-DSO structure in the kernel. > > When ELF loading it, stashing the contents of an ELF session > (.note.gnu.build-id) somewhere accessible at PERF_RECORD_MMAP3 > generation time. > > Doing that at the time we load the DSO from disk should add negligible > overhead. > > With that we would not need to go over all the perf.data stream to > generate the build-id table after all record sessions, they would be at > the struct map already. Yes, it'll solve the problem and simplifies the perf record. However I suspect it's not acceptable to keep such info in the kernel only for the sake of perf. > > We could then have multiple entries in the build-id table for the same > pathname, with different build ids, that is something we don't support > now and that provides bogus results when it happens. Maybe we can save and compare timestamp of build-id/map event and sample event. I'm experimenting to separate meta events (comm, mmap, ...) from sample events with a similar idea... :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html