There is a way, and Linux perf has an ID for every trace, ID which you can bind to any event string you can push into the perf file. But, in order to do that, I will need to add libpfm4 dependency to kprof2perf, which is not worth it. Instead I will go ahead to move the akaros to linux perf conversion, to the akaros perf tool (which already has the libpfm4 dependency), and drop the kprof2perf tool altogether. In order to do that though, I will need to know, on the Akaros side, the full path within the build directory, of the akaros kernel ELF file. A couple of solutions which come to my mind:
1) Build system create a magic build info file into KFS 2) Build info are stuck in a kernel ELF section, retrievable via system call or #some-dev-file On Sat, Dec 12, 2015 at 4:53 PM, Davide Libenzi <[email protected]> wrote: > On Fri, Dec 11, 2015 at 12:09 PM, Davide Libenzi <[email protected]> > wrote: > >> > +void perfmon_interrupt(struct hw_trapframe *hw_tf, void *data) >>> > +{ >>> > + int i; >>> > + struct perfmon_cpu_context *cctx = PERCPU_VARPTR(counters_env); >>> > + uint64_t gctrl, status; >>> > + >>> > + profiler_add_hw_sample(hw_tf); >>> >>> So it looks like we generate a trace whenever any of the counters >>> overflow, but >>> we lose track of which one overflowed. I guess that's what userland perf >>> expects? >>> >> >> I need to add an "ID", and figure out how to pass that to userland perf. >> Will do in follow up CL. >> > > Actually, doing it in this stream, as tail commits. > I already added an "info" field containing the event coordinates. > Need to figure out how to translate it for Linux perf now ... > > > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
