Re: [PATCH] perf tools: fix write_event()

[Peter Zijlstra]

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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/