lkml.org 
[lkml]   [2010]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] perf tools: fix write_event()
    From
    Date
    On Wed, 2010-01-20 at 12:26 -0200, Arnaldo Carvalho de Melo wrote:

    > > Can't report/archive/etc.. sort all this out?
    >
    > We need to record the buildids at record time, preferrably at
    > PERF_RECORD_MMAP time, from the kernel, for long running, low frequency
    > sessions were DSOs may be updated.
    >
    > Or for when a developer is updating his binary and doing perf record
    > runs to then use perf diff:
    >
    > perf record ./myapp
    > vi myapp.c
    > make
    > perf record ./myapp
    > perf diff

    > Works now because the first 'perf record' saved a copy of myapp so that
    > 'perf diff', finding the right build-id in ~/.debug/.build-id/ can do
    > the right thing.
    >
    > But till we send the buildid in an extended PERF_RECORD_MMAP event sent
    > from the kernel, I try to reduce the window by doing this at record
    > time.
    >
    > The current way of intercepting events at write_event() is deemed
    > broken, so I can do it atexit(), when we go to write the header, but
    > this will hurt because we'll have to reprocess it all.
    >
    > Yes, since we'd still have the window, we could do it on perf archive,
    > but it would be an extra explicit step and since I think the right place
    > to do this is at perf record (with the kernel injecting the buildid, if
    > present in the binary being loaded), I'd prefer to keep it that way.
    >
    > Then work on having the buildid stored in some suitable kernel data
    > structure and injected in the PERF_RECORD_MMAP event.

    OK, so my typical workflow is something like:

    perf record -o baseline ./foo

    # again:

    vi foo.c
    make
    perf record ./foo

    perf diff -i baseline -i perf.data

    # if good enough, quit, else goto again

    I don't find intermediate diff's all that interesting.


    So we could create a perf snapshot like command that collects everything
    (and maybe allow something like: perf record --snapshot), and have perf
    diff compare against that by default, instead of perf.data~ or whatever
    that was called again.

    As to buildids from kernel space, I don't think the kernel actually
    knows or cares enough about executable maps to be able to extract those.
    The initial ELF loader could (maybe) for the main executable, but all
    DSOs and esp stuff like dlopen() would become mightly tricky.





    \
     
     \ /
      Last update: 2010-01-20 15:41    [W:4.106 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site